DOCUMENT RESUME 



ED 243 471 



IR Oil 096 



AUTHOR 
TITLE 

INSTITUTION 

REPORT NO 
PUB DATE 
NOTE 

AVAILABLE FROM 

PUB TYPE 

EDRS PRICE 
DESCRIPTORS 



IDENTIFIERS 



Martin 
Guidan 
Report 
Nation 
Inst. 
NBS-SP 
Dec 83 
78p. 
Super i 
Office 
Guides 



Roger J.; Osborne, Wilma M. 
ce on Software Maintenance. Final Report, 
s on Computer Science and Technology, 
al Bureau of Standards (DOC), Washington, D.C. 
for Computer Sciences and Technology. 
-500-106 . 



ntendent of Documents, U.S. Government Printing-^ 
Washington, D.C. 20402^ 



- Non-Classrpom Use (055) 



MF01/PC04 Plus Postage. 

^Administrative Problems; ^Change Strategies; 
^Computer Software; Decision Making; Guidelines; 
Information Systems; Policy Formation; Program 
Administration; *Program Improvement; *ProgramiAg 
*ManagemBnt Cpntr61;> *Sof tware Maintenance 



ABSTRACT 

Based on informal discussions with personnel at 
selected federal agencies and private sector organizations and on 
additional research, this publication addresses issues and problems 
of software maintenance and suggests actions and procedures which can 
help software maintenance organizations mee.t the growing demands of 
maintaining existing systems. Software maintenance^ is defined as the 
performance of perfective/ ^adaptive, and corrective maintenance 
activities required to keep a software system operational and 
responsive after it is accepted and placed into production. The 
software maintenance process and the qualities of an ideal maintaiher 
are briefly outlined. Also discussed are factors to be weighed when 
deciding on system maintenance or redesign, control of software 
changes, and the improvement of software maintenance as a result of 
the policies, standards, procedures, and techniques instituted and 
enforced by management. Software maintenance tools, or computer 
programs that ,can be^useful in maintaining other computer programs 
and their documentation, are described. In a final section on 
management, emphasis is placed on the need for strong, effective 
technical management control of the software maintenance process. An 
80-item bibliography and examples of software maintenance definitions 
found in other publications are provided. (Author/ESR) 
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Gviidance On Software Maintenance 
Roger J. Martin and Wilma M. Osborne 



This report addresses issues and^ problems of softv^re 
maintenance and suggests actions and procedures which 
can help software maintenance organiza'tions meet the 
growing' demands of maintaining existing systems. The 
report establish-es a working definition for software 
maintenance and presents an overview of current 
problems and issues in that area. Tools and 
techniques that may be used to improve the control of 
software^ maintenance activities and the^ productivity 
of a software maintenance organization are discussed. 
Emphasis is placed on the need for strong, > effective 
technical management control of the software 
maintenance process. ^- 



Key words: adaptive maintenance; corrective 
' maintenance; management; perfective maintenance; 
software engineering; software maintenance; software 
maintenance management; software maintenance tools. 
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0 BACKGROUND ' , 

The Institute for Comput^er Sciences and Technolo&y (ICST), 
within the National Bureau • -of Standards (NBS), has a 
responsibility under Public Law ag-BOG (Brooks Act) to 
promote cost effective selection, acquisition, and 
utilization of automatic data processing resources within the 
Federal Government. ICST efforts include research in 
computer science and technology, direct technical assistance, 
and the development of standards and guidelines for data 
processing equipment, practices, and* software. As part of 
this responsibility and the growing need to improve software 
maintenance methods and management, the ICST is- developing 
software maintenance guidance designed to assist Federal 
agencies in the ongoing support of existing computer sj('>s(Stems . 
While software systems vary in function^ type, and size, many 
of th^ functions performed under software maintenance are 
universal in scope and the activities required to keep them 
operational are generally the same.. This is the. first in a 
series of reports which address both the management and 
technical t>ractices, procedures, and ^methods for -software 
maintenance. 

This report provides general guidance for managing software 
maintenance efforts. -It presents an overview of the various 
aspects and problems of software maintenance, and identifies 
those techniques and procedures designed tq assist management 
in controlling and performing software maintenance. It 
addresses the need for a maintenance policy with enforceable 
controls for use throughout the softwar^ life cycle. The 
undi^rlying theme is that improvements in'^the area of software 
maintenance,^will come primarily a^s a result of the software 
maintenance''^ policies, standards, procedures, and techniques 
instituted and enforced by management. 



. 1 Introduction 

There is a growing interests in < software maintenance as 
evidenced by the number'of articles, reports, and textbooks 
on the^subject (bee Bibliography). This interest has been 
spurred by estimates that more resources are required to 
maintain existing 'systems than to develop^ new ones. Federal 
managers respo/fsible for software application systems 
estimate tha%Jife% to 70% of the total application .software 
resources are spent on software maintenance [GA08la] [GA080?:i 

Two of the major causes bf this software maintenance burden 
are the ^ growth of the inventory of software 1|hich must be 
maintained and the failure to adopt and 'utilize improved 
technical and management methods and tools. The issue which 
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must be addressed is. not one of reducing th'e absolute cost of 
software main te^nance , but rather improving the quality, and 
effectiveness of software' maintenance and thus reducing the 
relative or incremental costs. . ' ^ 

In order to improve the .quality and effectiveness, it is 
necessary to not ^ only improve software maintenance 
techniques, methodologies, and tools, -but to al so -improve the 
management of software maintenance. Th^is Guide discussed- the 
problems associated, with managing software -maintenance and 
software m.ain tainers , arid examines management methods which 
can reduce those problems. 

Informal discu'ssions were held with selected Federal age.ncies 
and private sector organizations to gain a better 
understanding of the current state gf 'soft^ware" Maintenance. 
These discussions provided bacricground information on 'current 
practices, procedures, and policies relating to software 
maintenance. This information, along with gaddi tio'nal 
research, is the basis for this report.'"^ 

The major* topic areas .addresse^d in these discussions were: 

Definition of software maintenance. 

Methods, and techniques in coordinating and^ 
performing softw^e maintenance. 

Major maintenance problems. 

Types of applications being c^niaintained . 

Developmental Ihistor^y of existing software. 

Main tenahqe^ staff profiles. 

Management of main teaance activities. 

Utilization of maintenance tools. . 

It was expected that there would be some Commonality in the 
information provided by these discussions. in fgct, while 
■each organization has problems peculiar to its environment, 
there was an extremely high 'degree of consistency, in the 
comments made and the problems cit-ed. , - 

The primary difficulties and deficiencies encountered in 
software maintenance fall into several categories:, software 
quality, environment,; management, use«s, and personnel. 
Specific problems which were consistently . mentioned are 
listed ' in Table 1 . 



1 . 
2. 

4. 
5. 

6? 

7. 
8. 



Table 1 



Software Ma in te nance Problems 



Software 



Env ironme'nt 



program quality 
software design 
software coding 
' - software documentation 
- programming languages used 

- lack of common data definitions 

- increasing inveht®ry 
-excessive resource requirements 

- growth 

- evolving/change 

- new hardware 



Management 



Users 
Personnel 



- maintenance controls^ 

- maintenance techniques and procedures 
^-maintenancetoolusage 

- standards enforcement 

- demanding more capabilities 

- lack of experience 

- image/morale problem-s 

- view of main te nance: 
unchallenging, unrewarding 



As can be>3een from the table, there ire both technical and 
management-* problems. It appears, however, that many of the 
technical problems are often the result of inadequate 
management control over the software maintenance process. 
These problems arise for at least two different reasons. 
First of all, there is a great deal of code which was not 
developed with ma in.tenance ' i n mind. Indeed, the emphasis has 
of'ien : been ,to get the program up and running without being 
'^hindered" by guidelines^ methodologies, or other controls. 
The second reason.^s , , tha t q-ver the life. cycle of a software 
system;:- the code^d logic which may have been well-designed 
;jnd iaipleiTiented'^V , often deteriorate due to an endless 
succession of '»qulck fixes", and pa tches which are neither 
well-deiigrted nor wel 1-documented . Thus, in today's vast 
'inventory 'of application systems, there are many programs 
whichZ/at the time of th'elr development were considered 
"sta-te-^of-the-arl, but today are, in fact, virtually 
unrna i.n ta Lnabl e . . 



/ 
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The need to maintain old, outdated, poorly documented systems . 
*was consistently cited as a -primary problem in software 
maintenance. -There appears- to have been some improvement in* 
the quality of software over the last four to five years. 
These improvements, however, have come mairjly - on an 
individual basis where a programmer , analyst, or line manager, 
has introduced dne or more modern programming practices (e.g. 
structured code, top-down design and development, peer 
review). There usually has not been a systematic adoption of 
these practices at a higher level within an agency. Nor has 
there been extensive institutional introduction of standards 
and guidelines for software development and maintenance. 

Sections 1.0 through 6.0 address the definitions and problems 
-of software maintenance. These sections present an overview 
of the software maintenance process and discus-s the primary 
technical and management software maintenance issues. 
Sections 7.0 through 10.0 address how to control and improve 
software maintenance through the adoption or use of various 
policies, techniques, and tools. 
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0 DEFINITION OF SOFTWARE MAINTENANCE 



Software maintenance is a commonly "understood" term for 
which there i^ no single definition. This lack of a standard 
definition often results in confusion for those attempting to 
address . the problems of software maintenance. Some examples 
of software maintenance, definitions are included in Appendix 
I. The following definition of software maintenance is used 
throughout this report. 

Software maintenance !§. p^rfQrm^nQQ Ql iM^fi. 

activities required to keep a. SfiliM^Jia' system 
operational and responsive after Is accgptQcl 
Placed into - production. 

Software maintenance then, is the set of activities which 
result in changes to the originally accepted (baseline) 
product set. These changes consist of modifications created 
by correcting, inserting, deleting, extending, and enhancing 
the baseline system. Generally, these changes are made in 
order to keep the system functioning in an evolving, 
expanding user and operational environment. / 



1 Functional Definition 

Functionally, software maintena^nce activities can be divided 
into three categories which/ were originally proposed by 
Swanson[SWAN76] : perfective, fdaptive, and corrective. 

Many software managers consider requirements specification 
changes and the addition of new capabilities tq be software 
maintenance. Although these areas were not addressed by 
Swanson, the definition of perfective maintenance has been 
expanded to include them. The three maintenance categories 
are defined in the following manner: 

Perfec t ive p ?aintenance ' includes all changes, insertions, 
deletions, modifications, extensions, and enhancements which 
are made to a system to meet the evolving and/or expanding 
needs of the user. 

Adaptive jr ^ain tenance consists of any effort which is 
initiated as a result of changes in the environment in which 
"a software system must operate. ^ 

Corrective maintenance refers to changes necessitated by 
actual errors (induced or residual "bugs" ) in a system. 
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Table 2 - Functional Definition Qf 
Software Maintenance 



Perfective 



changes, insertions, 
deletions , mod if ica't ions, 
extensions , and 
enha'ncements 



Adaptive adapting the system 

to changes in the 
environment 

Corrective : fixing errors . 



2.1.1 Perfective' maintenance 



Perfective maintenance refers to enhancements made to improve 
software performance, maintainability, or understandability ./ 
It is generally performed as a result , of new or changing, 
requirements, or ' in an attempt to augment' or fine tune the 
software. Activities designed to make the ' code easier to 
understand and to work with, such as restructuring or 
documentation updates (often referred to as "preventive" 
maintenance) are considered to be perfective. Optimization 
of code to make it run faster or use storage more efficiently 
is also included in the perfective ^category. Estimates 
indicate that perfective maintenance - compr ises approximately 
60%-70% of all software maintenance efforts. 

Perfective maintenance is required as a result .of both the 
failures and successes of the original system. If the system 
works well,- th^ user will want additional features and 
capabilities. If the system works poorly, it must be fixed. 
As requirements change and the user . becomes more 
sophisticated, ' there will be changes requested to make' 
functions easier and/or clearer to use. Perfective 
maintenance is the method usually employed to ke^p the system 
"up-to-date", responsive and germane to the^ mission of the 
organization. " . ^ 

There is some disagreement whether the addition of new 
capabilities should be considered maintenance or additional 
development. Since it is an expansion of the existing system 
3fter it has been placed into operation, and is usually 
performed by the same staff responsible for other . forms of 



EKLC 



- 7 - 



maintenance, it is appropriately classified as maintenance. ' 

Fine tuning existing' systems to eliminate shortcomings and 
inef'f iciencies and' to optimize the process is of ten r ef errecT 
to as "preventive 'maintenance" . It can have dramatic effec^ts 
on old, poorly written systems ^both in terms of reducing 
resource requirements, aod in making the' system more 
maintainable' and,* thus, .easier to. change or enhance. 
Preventive maintenance may' also include /the study and 
examination of ;a system prior to - occurrence of errors or 
problems. Fine tuning is an exc-eltent vehicle for 
introducing the programmer to th^ code, while at -the same 
time -reducing the likelihood of serious errors in the future. 



1.2 Adaptive maint^'nance ; ' ' - ■ ^ 

Adaptive maintenance refers to modiTica'tions made to a system 
to satisfy or accomodate changes in the . processing 
environment. These environmental changes are normally beyond 
the contror of the software maintainer and consist primarily 

of changes to the: ' » 

' j»k • 

' - rules, laws, and regulations that affect the system 
hardw.are configurations, e.g., new terminals, local 
, printers ' , 

data formats, file structures 

system software, e . g ., opera ting systems, compilers, 
utilities . 

Changes to rules, laws, and regulations often require- the 
performance, of adaptive maintenance on a system. These 
changes must often be completed in a very short time frame in 
order to meet the dates, established by the laws and 
regulations. If rules and their actions are implemented 
modularly, the changes are relatively easy to install. 
Otherwise, they can be a nightmare. 

Changes to the computer hardware (new terminals, local 
printers, etc.) which support the, applicatipn system are 
usually performed to take advantage of new and/or improved 
features which will benefit the user. They are normally 
performed on a scheduled basis. The usual goal of this 
maintenance is to improve the operation and response of the 
application system. 

Changes to data formats aad file- structures may require 
extensive maintenance on a system if it was not properly 
designed ahd implemented. If reading or writing of data is 
isolated in specific modules, changes may have less impact. 
If it is embedded throughout the code, the effort can become 
very lengthy and costly. - . 
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Changes to operating system software (compilers, utilities, 
etc.) can have varying effects on the existing application 
systems. These effects can range from requiring little or no 
reprogramming , to simply recompiling all of the source code, 
to rewriting code which contains non-supported features of a 
language that are no longer^ available under the new software. 

Maintenance resulting .from changes in the "requirements 
specifications by the user, however, is consi^^red to be 
perfective,, not adaptive, maintenance. 

2.1.3 Corrective maintenance 

Corrective maintenance co,nsists of activities • normally 
considered to be error correction required to keep the^ system 
operational. By its nature, corrective maintenance is 
usually a reactive process where an error must be fixed 
immediately. Not all corrective maintenance is performed in 
this immediate response mode;' but all corrective maintenance 
is related to the system not performing as originally^ 
intended. 

There.' are three main causes which require sjjstems to undergo 
corrective maintenance: 

1. Design errors ' * . 

2. Logic errors 

3. Coding errors 

Design errors are generally the 'result of incomplete or 
faulty design. When a user gives incorrect, incomplete, or 



unclear descriptions of the sy^em bein,g requested, or when 
the analyst/designer does not fully understand what the user 
is requesting, the resulting system will often contain design 
errors. \ ' 

Logic errors are the result of invalid tests and conclusions, 
faulty logic flow, incorrec/ implementation of the design 
specifications, etc. Logic errors are lusually attributable 
to the designer^ or previous maintainer. Often, the logic 
error occurs when unique or unusual combina tio/is of data, 
which were not tested during the develpprpent or previous 
maintenance phases, are encountered.' 

Coding errors are the result bf either incorrect 
implementation of the detailed logic design, or the incorrect 
use of the source code. These errors, are caused by the 
programmer. They are usually errors of negligence or 
carelessness and are the most inexcusable, but usually the 
easiest to fix. 
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0 THE SOFTWARE MAINTENANCE PROCESS' • 

The life cycle of computer ^'software covers' its existence from 
its qonce.ptiqn 'until tlie time it is no longer available for 
U'§e. There are a number of definitions of . the software life 
cycle which differ primarily in the categorization of 
activities or phases. One traditional definition is: 
requir ements. des^ignj im plementation . teiiilL&, and QPerqtlQn 
and maintenance . • . - " ' 

The req uirements phase encompasses problem definition and 
analysis, statement of project objectives, preliminary systerp/-' 
analysis, functional specification,' and design constraints. 
The design phase includes the generation , of software 
component definition, data definition, and interfaces which 
are then verified against the requirements. The 
implem entati on phas e entails program code generation, unit 
tests, and documentation. ' During the test phase^ system 
integration of software components -and system acceptance 
tests are performed against the requirements. The .QP^r^.ti,Q.n% 
and maintenanc e phase "covers the use and maintenance of the 
system. The beginning ^of the maintenance phase of the life, 
cycle is usually at the delivery and user acceptance of the 
software product set. ' 



Table 3 - SoTtware .Maintenance Process 



1 . Determination of need for change 

2. Submission of change request 

3. Requirements analysis 

4. Approval/rejection of change request 

5. Scheduling of task 

6. Design analysis • 

7. Design review 

8. Code changes and debugging 

9. Review of proposed code changes 

10. Testing 

1 1 . Update documentation 

12. Standards audit 

13. User acceptance 

14. Post installation review of changes and 
their impact on the system 

15. Completion of task 
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The process of implementing a change to' a production system 
is complex 'and involves >many people in addition to the 
maintainer. Table 3 outlines the software-- maintenance 
process. This process begins when the need for a change 
arises and gnds after the aser ha.s accepted the modified 
system and all documentation has b^en sati sf actorily rupda ted 

Although the process is, presented in a linear fashion, there 
are a number of steps where iterative loops often occur. The 
change request may be returned to the user for ^addition^l 
clarification; the results of- the design review may 
necessitate ad'ditional design analysis or even modification 
of the change request; testing may result in additional- 
design changes op recoding; the standards audit may -require 
changes to' the design documents, ;:sode, and/or documentiBtion; 
and the failure of the users to accept the system may result 
in return to a previous step or the cancellation of the task. 

One way of describing the ac ti v i ties- of . s6f tware maintenance 
is to identify them' as successive iterations' of the first 
four phases of the software life cycle, i.e. require mgnt;^', 
■ design , implementation ^ and testing . Software maintenance 
involves many' of the sani^/ activities associated with software 
development with unique characteristics of its own, some of 
which are discussed in the following paragraphs. 

Maintenance activities are performed within the context of an 
existing framework or s.ystem. The maintainer must make, 
changes within the existing design and code structure 
constraints. This is often the most challenging problem for 
maintenance personnel. * The older the system, the more 
challenging and time-consuming . ^the maintenance - effort 
becomes . 

A software maintenance effort is typically performed within a 
much shorter time frame than a development effort, A 
software development effort may span one, two, or^more years 
while corrective maintenance may be required within hours and 
perfective main tenance in cycles of one to six months. 

Development efforts must create all of the test data . from 
scratch. ' Maintenance efforts typically take advantage of 
existing test data and perform regression tests. The major 
challenge for the maintainer is to create new data to, 
adequately test the changes to'ttie system and their imjp^ct on 
the rest of the system. 
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^At.O SOFTWARE MAINTENANCE PROBLEMS 

The responses to the ICST survey ^ of selected Federal and 
private sector ADP organizations consistently cited a common 
set of software maintenance problems. Generally, these 
problems can be categorized as technic^al and management . 
Most of theS"e problems, however^ can be traced to inadequate 
management control of the software maintenance process.^ This 
section presents an overview of the te'chnical aspects of ^ the 
: (naintenance problems identified in the survey. Mana^gement 
' control issues are addressed in subsequent sections of this 
report. . , ' 

^.1 Software Quality 

Modern programming practices, wh'i/^h utilise a well-defined,, 
well-structured methodology in the designN^nidJimplemen ta tion 
of a software system, address at 'least one major software 
maintenance problem - poor program quality. ^The importance 
of these, methodologies, whether they are. formal or informal 
is to give ' structure and discipline to. the process of 
developing 'and maintaining software systems. While this may 
alleviate some of the software maintenance problems for 
• systems developed using these methodologies, it does not 
solve' the problem of existing systems which were designed, 
developed, and maintained without utilizing a disciplined 
structure. ' - 

A lack of attention to software quality during the design and 
development phases generally leads to excessive software 
maintenance costs. It should be clearly . understood during 
the design and development phases that the maintainability of 
the system is directly affected by the qualityj^ of the 
software,. • 

4.1.1 Poor software design ^ 

The design specifications of a software system are vital to 
its correct development and impT.ementa tiqn . Poor software 
design can be attributed to: 

- a lack of understanding by the designer of what the user 
requested. 

poor interpretation 'of> the design specifications by the 
developers. 

- the use of convoluted and complex logic to meet, a 
I requirement. ■ 

i disjointed segments which do not fit together Into a ^ 
nicely integrated whole. 

- a lack of discipline in 'design which results in 
inconsistent logic. ' ^ . 

- large, unmodular systems (or worse yet one large system 
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with no component segments ) which ape bulky, unwieldy, 
and very difficult to understand. 



1.2 Poorly coded software 

A great deal of existing software contains poorly written 
^code. As computer programming ev.olved, much of the code 

development was performed in an undisciplined, -u^istructiJI^ed ^ 
' manner. This resulted in 9 great deaL of software which does 

not effectively utilize toe programming language in which it 

is coded. Poor programmrftg practices exhibited by this lack 

of discipLine include: 

- unmeaningful variable and procedure names 

- few or no comments ^ 

- no formatting, of the source code 

- overuse of logical transfers to other parts of the 
program 

- use of non-standard language features of the compiler 

- very large, poorly structured programs. 

The task of. understanding poorly written code becomes even 
more arduous for "the maintainer when the program has been 
modified by different individuals and there is. a multiplicity 
of programming styles. Often, such code simply does not do 
w>hat it was intended to do. Even if this code produces 
expected results,* it is sometimes harder to use than 
anticipated; is not suited for the skill level available^ to 
use it; or is slow and unresponsive. Attempting to change 
such code without the aid of up-to-date specifications or 
other , documentation is often a time-consuming effort. 



1.3 Software designed for outdated hardware 

There are many problems associated w^ith maintaining software 
which was designed to run on previous generation, outdated 
•hardware. Oftentimes, the investment in the software is such- 
that it cannot be discarded or rewritten and mustbe kept 
functioning as efficiently as possible. The first difficulty 
is in finding maintainers ,who are ready, able and willing to 
maintaifi these systems. Few 'good' programmers wiLl be 
willing to work, on hardware which is unique and for which the 
acquired skills are not .relevant . to other potential work. 
The career advancement' opportunities f romV^orking on such a 
system are minimal to non-existent. Additionally, most 
systems of this type are very difficult to maintain. 




I.Aj Lack of common data definitions 




An application system (whether it is large or. small) should 
have common data definitions (variable* names, .data types, 
data structures, etc.) for all segments of the system. These 
common definitions entail the establishment of global 
variable names which are used\,to refer to the same data 
values throughout the system. In addition, the structure of 
any data array or record should be defined and used for all 
programs in the system. Problems invariably arise When two 
or more pr'Sgrammers .^oLndepferidently create data names and 
structures which conflict or do not logically • assoc iate with 
one another . ' , 

1.5 More than one programming language used ^ J 

The use of more th^n one programming language in an- 
application. system (for example, assembly language 
sut>routines to perform" speci fic processes in a Cobol program) 
is often the cause of many software maintenance problems. If 
the maintainer is not proficient in the use of each ofN the 
specific languages, the quality and consistency of the 
maintenance can be affected. Changes to any of . the 
languages, or corresponding compilers, may also necessitate 
changes t o the' appl ica tioh system. 

1.6 Increasing inventory 

Rapidly changing technology and its impact on the practices, 
procedures, and requir^ents in many - organizations, has 
resulted in a substantial growth in the number of new 
application systems. In addition, the average life 
expectancy ' of a software system has increased from about 
three years, decade ago, to seven-to-eight years today 

[GREE81].\ 



.1.7 Excessive resource requirements 

While some types of maintenance (especially enhancements) may 
legitimately result in increased resource , requirements, other 
maintenance often results in needless increases. This occurs- 
primarily because of the maintainer's inability to correctly 
and quickly determine the optimum solution for the required 
change. The changes are accomplished by making a "patch" to 
the source code (or worse, to the object code) which doea not 
fit well and is not carefully integrated into the system. 
Subsequent maintenance efforts may compound this problem 
until the resource ^requirements become excessive. 
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2 Documentation 

One oX the major, problems in software maintenance can be 
summarized in the single phrase - " a failure to 
communicate." The maintainer. whoVr ecei ves the assignment to 
perform -maintenance on the systeffi must first understand what 
the program is doing, how it is^oing it, "^nd why. This job 
is greatly simplified if the original requester, the 
designer, the developer, and the previous maintainers have 
communicated all the pertinent information about the system. 
This communication should include design specifications, code 
comments, programmer notebooks, and other documentation. 

Too often^ Jthe maintainer receives little, no, conflicting, * 
or incorrect communication, from \th.ose who have previously 
handled the system.^ There is often inadequate documentation; 
no detailed record of the original request and subsequent 
updates; .no explanation of existing code and changes which 
have .been made to the code; a weak understanding of new user 
requests; and no explanation concerning why _ seemingly 
complex or convoluted logic and coding structured were 
selected over a more simple implementation. » 

Thus, the problems of software maintenance begin simply with 
a breq^kdown in communicafc;i^on between those involved with 
ensuring that the system does what . it is supposed to do. 
This communication is hampered . -by, the inability of those 
in>^lved to speak .the same language (jargon), the inability 
to ^understand the basic requirements (users not understanding 
computing; programmers not understanding user requirements) , 
and most, importantly the time Vf rame in which the actions 
occur. ' There may be months or years between the original 
development of a- system and each subsequent maintenance 
activityi. When a problem occurs, none of the individuals 
involved with the original design, implementation, and 
previous maintenance may be available. The only source of 
information available may be the documentation and the code. 
Thus, good docutrifentation is the only means for good, 
communication'. (The more « complete, clear, and concise this 
communication is, the greater the chance that maintenance can 
be per4;^rmed in a tifhely, efficient, and accurate manner. 
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Users 



Users are often unable to concisely specify what they want 
from - an application system . The initial requi rements 
definition and design often lack the d4tailed specificity 
iWhich would enable the developer to create a system which 
accurately performs all of the functions the user needs. 
Thus, 'an i,ncomF)lete system, is placed into production. The 
maintainer must' enhance the' system using the initial, 
inadequate specifications and .the new, sometimes vague', 
sj^etimes conflicting, often incomplete, change requests from 
the user . 

If a system is well-specified,' ^ well-designed, 
well-implemented, and' does what the user needs, the user will 
often think of things to add. The old adage that "nothing 
succeeds like success" hol-ds true for software developrrient 
and maintenance. The more successful a system is, the more 
additional features the user will think of. If the system 
works well, the user will be constantly, demanding mare 
features. If it does not work well, there will be a constant 
d.emand for reihedial action to make it function properly. 
Ther.efore, 'it is essential' that management establish and 
enforbe controls to ensure that the change requests are both 
justified and do not interfere with the maintenance workload. 

User requests for ' changes and enhancements which are 
excessive, conflicting, or vague have a major impact on trie 
maintenance of an application system. Much of the difficulty 
in this area stems from the fact that the. user is often 
unaware of the impact that one c-hange can have on^ both the 
system and the maintenance workload. The number of user 
requests for a specific system is usually . directly 
proportional to the' success of the original system and the 
previous maintenance efforts. A careful and thorough 
management, review of user change requests is essential for 
controlling the level of software maintenance and ensuring 
adequate feedback to the user on the cost apd consequences of 
each request. 



4 Personnel 

A common and widespread complain t by maintenance personnel is 
that software, maintenance i>s considered to be unimportant, 
unchallenging, unrewarding, uncreative work which is not 
appreciated . by the user or by the rest of the ADP 
organization. Software maintenance requires the efforts of 
experienced, well-qualified, ^ dedicated professionals. It 
should not be solely the responsibility of the new or junior 
staffs. With the development of more multi-purpose, complex 
software systems, there is. a greater need for software 
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maintainers who 4^an readily understand the entire system. 

Traditionally, management has not . rewarded personnel who 
performed^ software maintenance as generously as those who 
performed software development. ' ' It was generally thought 
that systems .analyst.s, designers^ and developers were 
responsible for the most difficult,, challenging tasks, ' and 
ther^i^e, must be~ more capable. ' ^ 

While this^attitude is still .coihmorli,- there is an iri'creasing 
awareness by management^ of the importance of software 
maintenance to cflhe successful, • smooth operatxQn of . an 
organization. Many technical personnel , however, still view 
software maintenance as an assignment to be avoided at all 
costs* There i^ too often a general lack of recognition that 
a good maintainer must be 3 . highly skilled, (Competent 
programmer and analyst concerned both with making the actuaT 
changes and with assessing the impact of those changes on the 
system and its environment. 



TllK IDEAL MAINTAINB:R 



Softwure maintenan.ce . is the lifeblood of an ADP organization. 
Persons asslgfi^d to •perform maintenance must effectively meet 
the challenge of maintaining a software system while' keeping 
the' user satisfied, costs 'down, '^ahd th-e system opera ti ng 
of f ic ieiitly . ' " '■ ■ . , . 



Yh.e cli ar a c t cr i s t i c 
include': 

" : :' Flex ibili ty - 
changing styles 



qualities' of " this . ideal /' ^ main tainer 



Ih^ ability to adgpt . to '^.'dlf ferent or 
of coding, user requests, and priorities. 



^Seif-motlvatiori - the ability to. . independently 
and complete \fork after receivtingi an assignment. 

R e sp o n s i b i f i^ > r e 1 i a b il ity ; p e r f arm ance 
tasks' In a dependable timely mann.er. . / 



ini tiate 



of assigned 



.Cr ea ti V i ty - 
idea's which 



the ability to apply • innovative 
-esult in practical solutions . 



and ' . novel 



Discipline- the ability to -be consistent in . th^ 
performance of duties and not^ prone to trying haphazard 
approaches . . ^ • 

Analytic - the ability to apply well ' though.tout analysis 
tOr' a problem.. 

Thorough - to address'' even the 'smallest detail - to ensure 
that all aspects 'of the problem are understood and n.Qthan^ 
;• is left uptested. .* . = ' * 



Experience ; ■ 
a^ipl ications 



to .have'.^' been ' ex,ppsed' VO 
and prog'rammrn'g env ironnients . 



a variety of. 



'The r ibeal '' 'main'tainer should - . be-, a senior., experienced 
•professional w\ib. can' perform all o'P the. functional activities 
which". p.fccur during^ the software, life .cycle.' Equally 
important- ■•from a .--tnaintenance standpoint,, ^the maintainer 
should be ex.tremely krtowledgeable., about ':the,.^^^^,^^^ system 
■'before attempting ^oi chaiage-'.^t'. ■■ ' ;,. . . ^ ' '.' .■ ' 

The maintainer must be able,' to .^analyze- the' the^ 
impact on the program, determine the requirements and design 
changes necessary for the- Sdlution, test the 'solution .until 
the desired results are obtained, and then . reie,ase.;tl^e. 
revised' software to operations^ or the user.. The maintainer s 
'task Us both intellectually and .technically difficult. 
Maintenan-ce is an activity where everything that can gO- wrong 
eventuaily does. The problems will continue to surface and 



enhancements will be requested as long as the system is used. 
It is 9 function which must be anticipated and planned for. 
It is also a function for which there may be an ^ unending 
succession of. emergencies to which st'aff must be assigned 
from other "more important" work. 

The maintainer is also.. an intermediary between the 
-application. systems support staff and tjje 0 users. 
Mainteriance, unlike development, cannot start with a clean 
slate and not be iaffected by previous decisions and work. It 
often takes a great, deal of time and patience to analyz^e both 
the' users needs and the existing system, and then to 
carefully' and adequately implement the existing changes. 

In the final analysis, the most important function of an 
application .system software support activity is software 
maintenance. It is the maintenance, and the response to the 
user problems which arise, which are always in the spotlight. 
Unfortunately, there is usually far less attention paid to 
maintenance when it' is done well and the users are pleased. 
Maintenance is an ongoing, almost . always intense, effort 
which should be spotlighted for its . successes, as well as its 
failures. 
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0 SYSTEM MAINTENANCE' VS SYSTEM REDESIGN 



Although ma^imtenance is an ongoing process, there comes a 
time ^/-vrirefi-' serious consideration should be given to 
redesigning a software system. A major concern of managers 
and software engineers is how to determine whether a system 
is hopelessly \flawed or whether it can . be successfully 
maintained. Admittedly, the thought" of software redesign may 
not be va c^fortable one. Nevertheless, the costs and 
benefit^ ol the continued maintenance of software which have 
become ^rrori-prone, ineffective, and costly must be weighed 
against trh^ of redesigning the system. 

While there are no absolute rules on when to rebuild rather 
than maintain the existing system, some of the factors to 
consider in -weighing a decision to redesign or maintain are 
discussed in this section. These/characteristics are meant 
to be general "rules of thumb" which can assist a manager rr\ 
understanding the problems in maintaining arf existing system 
and in deciding whether or not it has outlived it^ usefuljiess 
to the organization. 




Table '4 - Characteristics of Systems Which 
Are Candidates for Redesign 



1. Frequent system failures 

2. Code over seven- to- ten year s old 

3. Overly complex program structure and logic 

4. Code written for outdated hardware 

5. Running in emulation mode 

6. Very large modules or unit subroutines 

7. ^ Excessive resource requirements 

8. Hard-coded parameters which are subject to 
change 

.9. Difficulty in keeping maintainers 

10. Seriously deficient documentation 

11. Missing or incomplete design specifications 



When a decision has been reached to redesign or .feo stop 
supporting a system, ,the decision can be implemenfc^dt Cn a 
number of ways. Support' can simply be removed and the system 
can die thr-pugh neglect; the minimum support needed to keep 
it functioning may be provided while a new system is buixt^ 
or the system may be rejuvenated section by section and given 



an extended life. How the rerffesign is affepted depends on 
the individual circumstanc.es of the system, its operating 
environment, and the needs' of the organization it supports. 

The potential for redesign as opposed to - continued 
maintenance is directly proportional to the number of 
characteristics listed in Table 4. The greater the num'ber of 
characteristics present, the greater the potential for 
redesign. 



1 Frequent System Failures 



A system which is in virtually constant need of corrective 
maintenance is a prime candidate for redesign-. As systems 
age and additional maintenance is performed an them, many 
become increasing fragile and susceptible to changes. The 
older the code^ the more likely frequent modifications, new 
requir^|LntSt and enhancements will cause the system to break 
down. nSf 

An analysis of errors should be made to determine whether the 
entire system is responsible for the failures, or if a few 
modules '•or sections of code are at fault. If the latter is 
found to be the .case, then redesigning those parts of the 
system* may suffice. 



2 Code Over Seven Years Old 

The estimated life cycle of a major application system is 
seven-to-ten years. Software tends to deteriorat^e with age 
as a result of numerous fixes and patches. If a system is 
more than seven years old, ^there is a high probability that 
it is outdated and expensive to run. A great deal of the 
code in use today falls into this category. After 
• seven-to-ten years of maintenarfce , many systems have evolved 
. to wherev additional . enhancements or fixes are very 
time-consuming to make. A substantial portion of this code 
is probably neither structured, nor well-written. While this 
code was adequate and correct for the original environment, 
char^ges in technology and applications may ,have rendered it 
inefficient, difficult to revise, and in some cases obsolete. 

However, if the system was designed and developed in a 
systematic, maintainable manner, and if maintenance was 
carefully performed and documented using established 
stan'dards and guidelines, it may be possible to run it 
eff^iciently and eff^tively for many more "years. 
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6.3 Overly Complex Program Structure And Logic Flow 

"Keep it simple" should be the golden rule of all programming 
standards and guidelines. Too often, programmers engage iir 
efforts to write a section of code in the least number of 
statements or utilizing the 'smallest amount of memorfc^, 
possible. This approach to coding has resulted in complex 
code which is virtually incomprehensible. Poor program 
structure contributes to complexity. If the system being 
maintained contains a 'great deal of this type of code and the 
documentation is also severely deficient, it is a candidate 
for redesign. 

Complexity also refers to the level of decision making 
present in the code. The greater the number of -decision 
paths, the more complex the software is likely to be. 
Additionally, the greater the number of linearly independent 
control paths in a program, the greater the program 
complexity. Programs characterized by some or all of the 
following attributes are usually very difficult to maintain 
and are candidates for redesign: 

- eltcessive use of DO loops 

- excessive use of IF statements 

- unnecessary GOTO statements 

- embedded constants and literals 

- unnecessary use of global variables 

- self-modifying code 

- multiple entry or exit modules 

- excessive interaction between modules 

- moHules which perform same or similar functions. 



6.4 Code Written For Previous Generation Hardware 

Few industries have experienced as rapid a growth as- the 
computer industry, particularly in the area of hardware. Not 
only have there been significant technological advances, but, 
,the cost of hardware has decreased ten-fold during the last 
decade. This phenomenon has generated a variety of powerful 
hardware systems. Software written for earlier generations 
of hardware is often inefficient on newe^r systems. -.Attempts 
to superficially modify the code to take advantage of the 
newer hardware is generally ineffective, time-consuming and 
expensive. 
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5 Running In Emulation Mode 



One of the techniques used to keep a system running on newer 
hardware is to emulate the original hardware and operating 
system. Emulation refers to the capacity of one system to 
execute- a language written for another machine. In effect, 
it extends the architecture (hardware and software) of the 
host machine to include the range of the machine being 
emulated. This is normally done when .resources are not 
available to convert a system, or the costs would be 
prohibitive. These systems run a very fine line between 
functional usefulness 'and ^ ..totgl _ obsolesc^ce. One o^ the 
major difficulties in maintaining this type of system is 
finding maintainers who are familiar with the original 
hardware and who are willing to maintain it. Since ^ythe 
hardware -outdated, * the specific skills deVelpped^'^n 

maintaining the system, have little applicability elsewhere. 
Thus, the career development potential of supporting such a 
system is not very promising. 

6 Very Large Modules Or Unit Subroutines 

"Mega-systems", which were written as one or several very 
large programs or sub-programs (thousands / or 

tens-of- thousands of lines of code per program) can/ be 
extremely difficult to maintain. The size of a module is 
usually directly proportional to the level of effort 
necessary to maintain it. If the large modules can be 
restructured and divided into smaller, --functionally related 
sections, the maintainability of the system will be improved. 

7 Excessive Resource Requirements 

An application system. which requires a great deal of CPU 
time,, merrtory, storage, or otheo system resources can place a 
very serious burden on all ADP users • These "resource hog"' 
systems which prevent other jobs from running, may not only 
require the addition of an extra shift, but may degrade the 
service to all users. Questions whi,ch should be answered 
when deciding what ^o do about ^uch a system include: 

\ - Is it cheaper to add more computer power or to 
redesign and reimplement the system? 

- Will a redesign reduce the resource requirements? 
If it won*t, then there'is no use in redesigning. 
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8 Hard Cfeded Parameters Which Are Subject To Change 

* 

Many older systems wel-e designed with the values of 
parameters used in performing specific calculations "hard 
coded" into the source code rather than stored in a table or 
read in from a data file. When changes in these values are 
necessary, (withholding rates, for example) each program in 
the system must be examined, modified and recompiled as 
necessary. This is a time-consuming, error prone process 
which is costly both in terms of the resources necessary to 
make the changes and the del«y in getting the changes 
.installed. 

If possible, the programs should be modified to, handle the 
input of parameters in a single module or to read the 
parameters from a central table of values. If this can't be 

' done, serious consideration should be given to redesigning 

■. the system . , 

.9 Difficulty In Keeping Maintainers 

Programs written in low level languages, particularly 
assembler, require an excessive amount of time and effort to 
maintain. Generally, such languages are not widely taught or 
known. Therefore, it will be increasingly difficult to find 
maintainers who already know the language. Even if such 
maintainers ar.e found, th^ir experience with low-level 
languages is probably dated. 

.10 Seriously Deficient Documentation 

One of the most common software maintenance problems is the 
lack of adequate documentation. In most organizations, the 
documentation ranges from nonexistent to out-of-date. Even 
if the documentation- is good when delivered, it will often 
steadily and rapidly deteriorate as the software is modified. 
In some cases, the documenta.tion is up-to-date, but still not 
useful. This can result when the documentation is produced 
by someone who does not understand the software or what is 
needed. 

Perhaps the worst documentation is that which is 
well-structured and formatted but which is incorrect or 
outdated. If there is no documentation, the maintainer will 
be forced to analyze the code in order to try to ^jnderstand 
the system.' If the documentation is physically deteriorated, 
'the maintainer will be skeptical of it and verify its 
accuracy. If "it looks good on /> the surface, but is 
technically incorrect, the maintalher. may mistakenly believe 
it to be correct and^accept -what it contains. This will 
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result in serious problems over and above those which 
originally necessitated the initial maintenance/ 



IV Missing Or Incomplete Design Specifications 

Knowing "how and why" a system works is essential to good 
maintenance. If the requ^ements and design specifications, 
are missing or incomplete, the task of the maintainer will be 
more difficult. It is . very important for the maintainer to 
not only understand what a system is doing, but how it is 
implemented, and why it was designed. Missing or incomplete 
design specifications often result in end products which do 
not perform as intended.* ' The user must then request new 
changes and enhancements. 
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7.0 CONTROLLING SOFTWARE CHANGES 

The key to controlling software maintenance is to organize it 
as a visible, discrete function and, to the extent possible, 
plan for it. It is not enough for the software manager to 
manage the budget, people, and schedules. It is equally 
.important that the software changes be managed and 
controlled. ^ ' • 



Table 5 - Sugges,ted Policies for Controlling 

Software Changes 



1. Require formal (written) requests for all changes. 

2. R^y.xew all change requests and limit changes to 
tha)§>e approved. 

3. Analyze and evaluate tlV^type and frequency of^ ; 
change requests. 

4. Consider the degree to which a change is needed 
and its anticipated use. 

5. Evaluate changes to. ensure that they are not 
incompatible with the original systetti design and 
intent. No change should be implemented without 
careful consideration of it ramifications. 

,6. Emphasize the need to determine whether a proposed 
change will enhance or degrade the system. 

7. Apprdve changes only if the benefits outweigh the 
costs. ^ ' 

8. Schedule all maintenance. 

9. Enforce documentation and coding standards. 

10. Require that all changes be implemented using 
modern, programming practices. 

11. Plan for preventive maintenance. 
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1 Controlling Perfective Maintenance 

Perfective maintenance comprises an estimated 60%^ of -the 
total maintenance effort. It deals primarily with expanding, 
extending, and enhancing a system to give it greater power' 
more flexibility, additional capabilities, or greater 
reliability. Requests for perfective maintenance are 
initiated by three different groups: the user, upper 
management, and the maintenance staff. * 

The user is almost never completely satisfied with a system. 
Either it does not perform up to expectations, or, as the 
user gains confidence in the system, additional features 
become obvious and the maintenance staff is asked to add 
those features. This is a normal evolution in all software 
systems and. must , be planned for when developing budget 
requests and resource allocation schedules. 

Upper management drives the perfective maintenance process. by 
requesting new and enhanced ,„ features which must be 
incorporated into existing application systems. Once again, 
this is a normal part of the functioning of any organization 
and must be planned for in the maintenance budget. 

Finally, the maintenance staff drives the perfective 
maintenance process. As a maintainer works with a system,' 
inefficiencies and. potential problems are often found." These 
problems, while not requiring immediate attention, are such 
that at some point in time they could have a significant 
impact on either the functioning of the system or on the 
ability to maintain it. Thus, the "cleaning up" of code 
(often referred to as "preventive maintenance") is an 
important perfective maintenance process which should be 
planned for and included in the resource allocation schedule. 
The proverbial "stitch in time" of preventive maintenance can- 
often prevent minor problems in a systems from becoming major 
problems at some later date. . This undoubtedly will make 
future m^aintenance easier as a result of the "cleaning up" of 
the code. , ' 

The management of perfective maintenance deals primarily with 
maintaining an orderly process - in which' all requests are 
form§-lly submitted, reviewed, assigned a priority, and 
scheduled. This does not mean that' unnecessary delays should 
be built into the process, or that in small organizations 
these steps are not consolidated. Rather, it defines a 
philosophical approach which can help' the maintenance manager 
bring order to the maintenance environment. 

There should be a centralized approval point for all 
maintenance projects. ,., This may be the maintenance project 
manager or, for larger systems or organizations, a review 
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board. Changes should not just happen to a system. When the 
need for a change or enhancement arises, a formal written 
request should be submitted. ' Each request should be 
evaluated on the basis of resource requirements, time to 
complete the work, impact on the existing system and other 
maintenance efforts, and justification of need. The 
centralized approval process will enable one person or group 
of persons to have knowledge of all the requested and actual 
work being- performed on the system. If this is not done, 
there is the likelihood that two or more independent changes 
to the system will be in conflict with one another and as a 
result, the system will not function properly. Additionally, 
different users will often request the same enhancements to a 
system but will have small differences in the , details. By 
coordinating these requests, details can be combined ^nd the 
total amount of resources required can be reduced. 

' If the system requires maintenance as a result of changes in 
policy or procedures in the' Organization , an evaluation of 
the cost and effects of the changes should be prepared for 
upper management. Ideally, this should be prepared prior to 
the decision to institute the changes, but even if It is- not, 
management and the users must be aware of the costs. Users 
often request enhancements to a system because it "would be 
nice to have" or another .system has a similar feature, c These 
requested enhancements should be evaluated and the estimated 
costs reported to the user. Regardless of whether or not the 
users are responsible for funding the work, it is important 
to keep them aware of the actual costs of their requests . ' 
Doing so will help to minimize the amount of qnneeded . -.or 
marginally needed enhancements which must be instalTed on the 
system. In addition, this type of interchange with tlje user- 
will help the maintenance manager in evaluating and assigning 
priorities to the work requests^ 

In many organizati^ons there is a significant backlog of 
maintenance work requesj^^s. 'Users need to understand the 
level of effort required to meet .their requests and ' the 
relative priority of the Work in relationship to other user 
requests. This can only be accomplished by involving all 
parties in the discussions and keeping everyone informed of» 
the schedules and actual progress.' 

7.2 Controlling Adaptive Maintenance 

Adaptive maintenance comprises approximately 20% of the 
maintenance^ burden. - It consists of any effort required to 
keep a system functioning as a result of changes in the 
'environment in which It must operate, and is, to a great 
degree, beyond the -control of the software maintenance 
manager. Changes to the operating system, systejn utilities. 



terminal devices, and the rules, laws, and regulations which 
the software must incorporate, are the primary causes of 
adaptive maintenance. The maintenance efforts required are 
usually non-productive in terms of improving the application 
system. ' 

There is little that the software maintainer can do to 
control changes to rules and legislation. These changes, to 
the extent possible, should be anticipated and "the code 
structured in a manner which facilitates making the needed 
changes. This type of adaptive maint£nance usually must be 
^erform^d whenever it is required. Management should always 
be given feedback regarding the impact that changes in 
policies and regulations have on the maintenance of a system, 
.especially the cost. This feedback will impr'bve the future 
decision making process and may reduce ,the level of adaptive 
maintenance. • ' . — . 

In many organizations, the application support organization 
functions. independently - of ■ the computer facility 
organization. As a result, there is inadequate. communication 
and understanding by each group regarding the impact of 
decisicns and work on the other function. Th-us, changes may 
be made to the environment and announced to^ the user 
community without giving the application support function an 
opportunity to analyze the impact of the charf^^s and the 
effect on the application system. Similarly, changes or 
additions to an application system which increase the 
computer resource requirements may cause serious problems 
with the functioning of all applications usingi the computer. 

Therefore',' it" is - very" important that ■ the facilities 
organization and the applications support organization work 
closely to minimize the impact of one organization's wlork oh 
the other organization. There . are times when, a choice simply' 
does not" exist, but usually, through adequate planning and' 
eval^jation, both . organizations can accomplish their' 
objectives with a resulting net improvement for each. 

The ■ application support manager has the responsibil:j.ty to. 
.i<now what changes to the env, iron|nent are being planned aftd 
considered, and . to. keep/ " ma;nagement/ • i of their 

potential • impacit ■ Xboth^- 'n^^ -.In doing 

this,- tf3.e total posts and the implications of. the chan'ges can 
be I reviewed by ■ management'. Decisions can then . be made 
regardingswhich' organization should bear the costs' ' of,, . the 
resulting required adaptive maintenance of the appl'le'a tlon 
systems. ■ . , > . • 
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7.3 Controlling Corrective Maintenance 

Corrective maintenance is primarily the identification and 
-removal of errors, bugs, and other code defects that either 
reduce the effectiveness of the software or .render the 
product useless. This category of maintenance is concerned 
with returning the code to an operational state. Controls 
are needed to ensure that the occurrence of errors or bugs 
are the exception rather than th'e ic,^Te. 

Most of the cost of software maintenance is often assumed to 
be the result' of poor workmanship durilig development and 
priot- maintenance phases of the system. While this is a 
contributing cause, it is very rare for ev.en a 'iperfect' 
system to not require significant maintenance during its, 
lifetime. While software does not "break" in the sense . t^f^,. 
a piece of hardware can fail, it can become non-fg^ictioria^lx,^^ 
or faulty due to changes in the environment in whifjh it must,, 
operate, the. size or sophistication of the user Icommunity, 
the - amount of data it must process s, or damage to code which 
is. the result of other maintenance efforts on other parts of 
the system. Corrective maintenance is, necessitated by 
: .discovery of a flaw which has always ex^^ted, in the system or 
was Introduced during prior maintenance.-;/ , 

Difficulties encountered diiring corrective maintenance can he 
reduced significantly by the adoption and enforcement af 
appropriate standards and procedures during the development 
and mainterian'ce of .the software-. While it is probably not 
possible to; eiiminateCcorrective maintenance, the consistent 
and 6isc>iv^in^a adh^r^xice to effective design and programming 
. standards. x:an, 'an'd":wip, signi f icantly^rfcjuce the corrective 
maintenance^ . burden .3 -..d 
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0 IMPROVING SOFTWARE MAINTENANCE 



'Maintainability is the ease .with ; .wh,ich' software can b.e 
ch-anged to satisfy user requirements'- or can' .be corrected when 
deficiencies are detected, The maintainabiMty of a . system 
must be taken into consideration, throughout. th,e life cycle of' 
that .system. Many techniques and aids 'exists to assist th^e 
system^ developer, • but' there has been 1 ittielerriphasis on aids 
for the .m.aintainer . . However,, since the prpces^s'es 'whlch -oc 
in the. maintenance phase are similar ...to. .: thos^^^^^ the 
development phase, there is' considerable.; 6v^r.Iap.^'in the 
applicability of the development / . aids . in the tbal'ntenance 
env ironment 1 . : * • . ; . / 



The philosopln^'s , procedures,, and techniques .idiscu^sed in 
this section should be utilized throughout the. i'ife. cycle of 
a system in order to provide maintainable software..' Software 
systems which were not developed using these techhiques can" 
also benefit from thejr application during ma j or ..'main tenance- 
activities. In other wordis, if a system must be maintained, 
the maintainability of. the'isystem can; be improv^ed by applying 
the ideas/ discussed in this . section' to the parts of the 
system ^hlch are modified dumping the maintenance process. 
While tiier'; effect will not *be; as profl6unped as when programs 
are "developed with main tenance in mind future maintenance 
efforts can be made easier^';, by -utilizing the techniques 
described in this section ^o^;: "niaintain.V' systems with future 
maintenance in. mind"^^ 




Table 6i - Factors Which lAf fee t Sj6:5a?^e 



Code Maintalnabil ity./^ ' 



1. Use of.Jp^single high oroew^anguage 

2..' CdAiBiMkt>nventi6ns for variable names, 
^^s, .if ormat , grpuplng, etc . 

and modularity 

> f|^;:f!-%^^ data definitions 

'7^^^^^ comments in the code 

6. Avoidailbie of compiler extensions 



■ ^•l\/y'\Sjcy^rQ^^^^ Guideli-n;es ■' ' v^^^ '. ' 

■ : • ■•':i$iLr^^^ guidelines and standards aid"; Wintain 

-' -^^ a structure and framework with-in,.,Vihich systems caa 

•" ' be developed and maintained in a cpmipohv^^^ - ea§ily 

understood manner. ^ ' .■y 

8.1.1 Use a singl^e-high-order language -v^ • 

The use of more than one programming language, , or . the use;, of ., . 
• machine, assembler or outdated languag^e&V-: ;When ! it is not • 
. absolutely necessary to do so, can ^er^ioualy-'v'ijnpact the . 
' . maintainability of a system. When more than 'ohe-: language . is 
'employed, the potential for 9ommunica tion problema-, ,.^?tw,een 
modules is increased. Systems written in loV-o.rder or 
outdated languages are difficult to maintain because they 
goneralfi*' require more source code to perform the same, amount • 
of wdO.'/wherever possible, a single high order language 
( HOD-^rrifuld be used. Advantages of using a HOL include.: 

^ . - HOLs resemble English and -are easy to learn, r'^.^d 
and understand; 

" v \ J There are standards for the commonly used HOLs • - 

.:V-''-.-;/ (COBOL and FORTRAN). ^ * ; 

■ f *.:-^V - There are a sub5ta'ntial number of programmers who ^ 
. understand and dan -Ci^^. HDt^ ef fecti^vely ..-o- J 

- ■• . ■■■ .. '^ • '/.V' ■ 

■■ . ■ ; - '^Many. o/ the al(jef . mS^^^^^ languages are noV' longer 
. ■;, GuppGrfced byr^the ;nianuf actur er . 

•■ ■ ' , ' ^ ■ . ■ ■ ." . , ' , " ^ " ■ 

■ Fewer prbgrVfajpervs understand machine languages, and 

* ■ v' ■ . f^^^w^r stilX f'e^r)* use them ef f.ec tively . '\ 

' -.HOCs are. sei-f-<lbcumenting to %,larg^e degre^V • a . 

, ■ . . • . . . ' *. . y^'^ ' ' ' ' ' •■ 

, It . i5 easier to move from one eovirt)nme*nt^::to another 
wi til an HOL . . 

X y X . . " , " ^ 

8". 1.? Coding,, conventions ' • ,• . 

The -flrat obstacle "a maintainer must conqyer is the code 
it:;ciT.' Unfortunately, a great deal of .the source code 
' wrltteA- by developers and maintainers is not written with the 
rutur*<;.;..jnalntain:er. in mind. Thus, the reacfability of source:,;; 
code- l.^: 6:(;teri poor.* , . . ' 
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Regardless of the programming language(s) used, simple' rules 
regarding the us,e ; of the language(s) and the physical 
formatting of . thie source code should be established. Code 
standards do not' have- t'o be lengthy or complex in order to be 
effective. In faot,^ like the code itself, the best standards 
are simple and short.' Jhe following techniques can improve 
program readability and should be used as the basis f.or a 
code standard, 

- - Keep it simple . Complicated, fancy, exotic, tricky, 
confusing, or "cute" constructions should be avoided 
/whenever a simpler method is available. Use common 
/ sense and write code as if you had tc picl^ it up and 
/ maintain it without ever having seen it''before, 

- Indentation , when properly utilized be;tween sections of 
code, serves to block the listing into segments. Inden- 
tation and spacing are bot^h ways to show subordination, 
.It is- ve/y difficult to, follow code which continues line 
after Mne without a break or change in form, . ' 

• ■ ' ' ' k'* 

Extensively comment the code with meaningful , comments,- 

Do jpQpt comment ;;:f or comme\:it's sake. Rather, comment in 

ord'^^jf;^, to communicate to subsequent maintainers not only 

^.t;. what was done and how it was done, but Why it was done 

•Vv/54n this manner, c 

'0 ^ . f 

-.^ Use of meaningful variable nart^^' :: -4^ ^ne of the most 
important coding principles /fap , ffei|low when developing 
and maintaining programs, Thet name of a variable should 
convey both what it is and,;0iy It^ used, V*' 

- Similar variable names should be avoided. Each variable 
name should be unique in order to prevent confusion, • 

- When numeric s are used, they should be placed at the end 
of the variable. Some of the more common errors are 
claused by mistaking variable names which begin with the 
numerics 0,V,2,5 for 0,I,Z,S, respectively. Numbers 

. ^ used 2^s program tags or labels should be sequential, 

- LQgi Q^ lly related functions should ')be grouped together 
in the same module or set of modules. It is extremely. 

• difficult to analyze the prqgram flow when ex^ecution 
jumps in and out of different portions of code. To the* 
extent possible, the logic flow should be from top to 
bottom of the program, * . 

^ - Avoid non-standard features of the - ,versioft' of the 
language - being. used unless absolutely necessary. Fail- 
ure to do so will exarcerb^te problems ".of conversion or 
. movement. 'of the program .to another machine or system. 



8.1.3 Structured, modular software;; 

While there, has been considerable debate-* regarding structured 
programming, the . consensus is that generallyV; such code is 
easier to reatJ; A structured program is constructed with a 
^V. .basic, set. of control structures which each have one exit and 
\:.one.v e Structured programming , technique^ 

''"^^€^ l-defan4d methods which incorporate top-down design and . 
implementation and strict use of structured prggramming 
constructs. Whether the strict definition, or a more general 
approach (which is intended, to organize the code and reduce - 
its complexity ) is used, stV-uctured ' programming has proven to 
be useful i;i improving the maintainability of a system. 

Modularity refers *to the structure of a program. A program 
comprised of small, hierarchical units or sets of routines, 
wherre each performs a particular, unique function, is said to 
be modular, ./^'^-^li,, is not, as is often thought, mere program 
segmentation.-.-^^ module is said to have two basic 
determinants: cohesiveness -and coupl ing,.;,,,_ 

Cohesion refers to the degree to wHich the functions or 
processing elements within a module^ are related or bound 
together. It is the intra-module rela ti veness . The greater 
the cohesion, the less impact changes will have on the 
'software. . 

Coupling refers to the degree that modules are dependent upon 
each , other. The less dependency or interaction there is 
between modules, the better, from both a functional and a 
maintenance standpoint. A high degree of cohesion almost 
always assures lower degree of coupling. Controlling 

^cohesion andV^ o are very effective techniques in the 

"design and^main tenance of structured, modular software. 

jOrte of th"e nriVst obvious advantages of designing and coding 
^- str^ modules is that if it is, determined that a 

WfUa'hction is no longer needed, only that module is affected. 
The size of a mpdule is dependent upon its function. It 
should, however, be^- kept as small ^s possible. Modules 
should be constructed using the following basic design 
principles : 

- Modules should perform only one principal function.^ 



Interaction between modules should be minimal. 




- Modules should have only one entry and one exit point. 
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8.1.^ Standard data definitions 
^- . 

It is very important that individual modules of a system not 
only be 9ble to communicate with one another, but that the 
maintainer' under:?tand what is being communicatee!. A typical 
problem in a large multi-module system is that one person 
will use a set of names for data items which do not match the 
names used by another person on the team. Even more serious 
is' the use of the same' names to represent two different data 
items. Thus, it > is imperative that a standard set of data 
definitions be developed for a system. These data 
definitions will define the name, physical attributes, 
purpose, and content of each data element utilized in the 
system. .'These names should be as descriptive and meaningful 
as possible. If this is consistently and correctly done, the 
task of reading and understanding each module and ensuring 
correct communication, between each module is greatly 
simplified. ' . 



8.1.5 Well-commented code / 

Good commentary increases the intelligibility of source code. 
In addition to making programs more readable, comments serve 
two other vital purposes. They provide • information on the 
purpose and history of the program, its origin (the auxhor, 
creation and change dates)-, the name and number of 
subroutines, and input/output requirements and formats. They 
also provide operation control information, instructions, and 
.recommendations to help the maintainer understand aspects of 
the code that are not clear. 

Maintainers ('gnd managers) often mistakenly confuse quantity' 
for quality when writing comments. The purpose of comments 
is to convey ^information needed to understand the^ process and 
the reasons for implementing it in that specific manner, not 
• how -it is being done. Comments should be thought of as the 
primary form of documentation. They should include the 
following: 
4 

- what the code is doing, ' 

- why a process is being performed', 

- why' it is implemented in the specific manner, 

- how this section of code affects and interacts 
with other sections of code, 

- any known or potential problems, 

- when the changes were made, 

- who made the changes, 

- what specific code was^, modified, 

- any other information which might help a future 
maintainer in understanding and modifying the code. 
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8.1.6 Avoid compiler extensions 

The use of noi|,-standard ^features of a compiler can have 
^ serious effects on the ^ maintainability of a system. If a 
compiler is changed, or the application, system must be 
transported to a new machine, there is a very great risk that 
the extensions of, the previous compiler will not be 
- compatible with thei new compiler. Thus, it is best to 
refrain from languagel^ex tensions and to stay in conformance 
with the basic features of thfr language. If it is necessary 
to use a^ compiler extension, its use should be 
well-documented. 

8.2 Documentation Guidelines 

The documentation of a system should start with the 
requirements and design specifications arid 
throughout the life . cycle of the systert. Good 
(documentation , is essential to good maintenance. 



Table 7 - Documentation Guidance 



original 
continue 
software 



1. Keep it simple and concise. 

2. The maintainer's first source of documentation is 
the source code. 

3. The manager's first source of .documentation is the 
design specifications and implementation reports. 

4. The user's first source of documentation is the 
Users Guide and the maintainer. 

/ 5. Do not under document. Do not over document. 

6. Documentation cannot be "almost correct". Either 
it is up-to-date, or it is useless. 

7. 'Documentation maintenance is a vital part of ^ 

system maintenance. 

8. Documentation should be available to the 
miintainer at all times. 
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The documentation must be planned so a maintainer can quickly 
find the needed information. A number of methodologies and 
guidelines exist which stress differing formats and styles. 
While preference may differ on- which methodology to use, the 
important element is to adopt a documentation standard and to 
then consistently enforce adherence to it for all software 
projects. 

The success of a software maintenance effort is dependent on 
how well information about the system is communicated to the 
maintainer. Documentation should support the useable 
transfer of pertinent information. Documentation guidelines 
should include instructions on. what information must be 
prov ided, how it should be structured , and where the 
information should be kept. In establishing these guidelines 
and standards, keep in mind that the purpose is to 
communicate n^ecessary, ' Critical information, not to 
communicate all information. 

Basically, the documentation standards should require the 
inclusion of all- pertinent material in a documentation folder 
or notebook. This ^material should cover all phases of the 
software life cycle and must be kept ful.l^ tipdated..; 
Management must enforce documentation standards V- and ^ NOT' 
permit short cuts. There should be ^a Requirement t.b^tfo^n^^ 
and/or update documentation before n^evflwork assi^grtmehts 'af e 
begun, ^ ^ " '-^ .'-'^-l 

The key to successful docura.entatijo.n' is that not onlyfjnust the^^^ 
necessary information be ; .r.ecbirded , it must be easily and 
quickly retrievable by the maintainer. On-line documentation 
which has controlled access and update capabilities is the 
best form of documentation for the maintailier. If the 
documentation cannot be kept on-line, a mechanism must exist 
to permit access to the hard-copy, documentation by the 
maintainer at any time. 

If documentation guidelines, or any other software guidelines 
or standards, are -to be effective, they must be supported by 
a level of management hi*gh enough within the organization to 
ensure enforcement by all who use the software or are 
involved with software maintenance. Such guidelines, when 
supported by .management, will help direct attention toward 
the need for greater discipline in the software" maintenance 
process. 

For further information on documentation guidelines and 
standards, see [FIPS38], [FIPS64], and [NBS87]. 
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8.3 Coding And Review Techniques 

The techniques listed in this section have been found to. be 
very effective in the generation ^of maintainable systems. 
Not ,all techniques are generally applicable to all 
organizations, but it iS' recommended that they be considered. 



Q • Table 8 - Coding and Review Techniques 

1. Top down / Bottom up design and implementation 
2 . t Peer rev i*ews 

3. Walkthroughs ^ 

4. Chief programmer team 

8.3.1 Top down/bottom up approach 

A top-down design approach (development or enhancement?) 
involves starting at the macro or overview level and 
successfully breaking each program component or large, 
complex problem into smaller less complicated segments. 
These segments are^then decomposed into even smaller segments 
until the lowest leve!^ module of the original problem is 
defined for each branch in the logic flow tree. 

In general, top^own implies that major functions are 
considered first. Once it is clear how they fit together, 
th^ next, lower level functions are designed. During the 
first phase, the lower level functions are often created as 
empty black boxes or modules that simply return control to 
the major level or calling functions. 

The bottom-up design approach begins with the lowest level of 
elements. These are combined into larger components which 
are then combined into divisions, and finally, the divisions 
are "combined into a program. A bottom-up approach emphasizes 
designing the fundamental or "atomic" level modules first and 
then using these modules as building blocks for the entire 
system. 

Both of these approaches are valid and superior to a random 
"seat-of-the-pants" approach. In most situations, a 
combination of top-down and bottom-up can be utilized to 
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develop a clear, concise, maintainable system.* The adoption 
and adherence to either approach provides a .structure or 
■methodology which, enables ^persons working on a system to 
^••cbmmunica^te with one another in a manner which is consistent 
'• and understandable, , , 



8.3.2 Peer reviews 

Peer review is a quality assurance metho'd ,in which two or 
more programmers review and critique each other's work for 
accuracy and consistency with other parts of the system. 
This type of review is normally done by giving a section of 
code developed by one programmer to one or more other peer 
programmers who are charged with identifying what they 
consider to be errors and potential problems. It is 
important to establish and to keep clearly in the 
participants^ mirids^t^ the process is ^not an evaluation of 
a programiners capabilities or ^^^^ Rather it is an 

arialysi'S and evaluation of' th^ As stated in the name, 

such ; reviews are perfol^med ^'On a peer basis (programmer to 
; programmer) and should nevfrfbp. use(^ as a basis for employee 
evaluation. Indeed, pr^b^^ec:^; " managers should not,' if 
possible, be involved in the peer reviews. 



8,3.3 Walkthroughs 




Walkthroughs of a-^'pr*p'posed solution or implementation of a 
maintenance tasi«1^/can range from informal to formal, 
unstructured to structured, and simple to ' full-scale. The 
principle involvedgin^^walkthroughs is, simply that "two heads, 
are better ' than: one^lla its simplest form, a walkthrough can 
be two mait^te^n^rs;.sitting down and discussing a task which-^. 
one of th^rt \is^ workinji , on. In its more . complex forms, ther:# 
may be ^Vl sfcructuj^Ml'V agenda . report forms, and a recording 
s e c r e t ai ifc • n^g W^'i V or may not participate in 
walkthrcyC)^'; is an excellent way for a 

manager t^' k^q^ the work being performed by , 

the tean\',^-^:\y..^/l,^^'^^^ ■ 

The basic or m^^^ is for the* person whose 

work is V4)Um describe- in detail the proposed 

solution bir^B^^^^^^ code. The reviewer(s) ask(s) 

questions ^\ ^^ questions arise and point 

out any erriib5^o:r^^ which are spotted. The 

goal, as i'Avjpee^^^^ is to minimize the number of 

design, logicii'M: i^^^ flaws which remain in the 

system. Walkt^hr.pUg^^^^ to peer reviews, but differ 

in that the mahager-m^^ the reviewers meet as a 

group 'to discu;s;s;\theA^ consideration; and there are 

often formal recW'd 



Two important points should be stressed regarding the 
manager^s role in a walkthrough: 

!• Walkthroughs should never be used as part of an employee 
evaluation. The goal is an open, frank dialogue which 
results in the refinement of good ideas and the changing 
or elimination of bad ones. 

2. The manager^s role should only be as active , as his or 
her technical expertise regarding the subject matter 
permits. The manager must recognize that 'the other ' 
members of the walkthrough team probably have greater 
^ technical knowledge about the specific subject being 

discussed. Participating in a passive manner can be an 
excellent means to attain an understanding of the main- 
tena'nce effort and to improve the manager^s/ technical 
understanding of the system. 

8.3.^ Chief programmer team / 

The chief programmer team is based on the premise that' an 
experienced programmer, supported by , a team of programmers, 
can produce computer programs with- greater speed and 
efficiency than a group of programmers working under the 
- traditional line and staff organization . 'The size ^ of the 
team can range ^from 3-10, with the chief programmer being 
responsible for overall design, development, review, gnd 
' evaluation of the work performed by the members of the team. 
This can include the establishment and enforcement of rules 
regarding programming style, control, and the integrity of 
the programs. ♦ 

The chief programmer functions as the /ocal poin t of the 
maintenance team and is required to be aware and familiar 
with all work performed by 'the team. There is an ertormons 
^i^^l^^jl^' amount of administrative and technical responsibil ity placed 
M^^f;||i on the chief programmer. This person must have impeccable 
rv^^^lj:^^ leadership abilities, a strong technical capability, and^'the 
^v^'^/^ willingness to delegate work and responsibility. ^ 
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8.n Change Control - 

Change control is necessary to ensure that all maintenance 
requests are handled accurately, completely, and in a timely 
manner. It helps .assure adherence to the established 
standards and performance criteria for the system and 
facilitates communication between the maintenance team 
members and the maintenance manager. 



Table 9 - ^Controlling Changes 



1 . Change request. 

2. Code audit 

3. Review and Approval 



8.4.1 Change risquest 

All changes considered for a system should be formally 
requested in writing. These requests may ^be initiated by the 
user or maintainer in response to discovered errors, new 
requirements, or changing needs. ^ Procedures may vary 
regarding the format of a change request, but it is 
imperative that each request be fully documented in writing 
so that it can be formally reviewed. The review may be 
performed by , the project manager or a change review board. 
The key, however, is that there must Ipe a formal, 
well-defined mechanism for initiating a request for changes 
or enhancements to a system. - Change requests should be 
carefully evaluated and decisions to proceed should be based 
on all the pertinent ai^eas of consideration (probable effects 
on the system, actual need, resource requirements vs resource 
availability, budgetary considerations, priority , etc. ) . The 
decision and reasons for the decision should be recorded and 
included in the permanent documentation of the system. 

The change request should be submitted" on forms which contain 
the following information: 
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- name of requester 

- date of request * - 

- purpose for request (error reported , enhancement ,. etc ) 

- name of program(s) affected 

- section of code/line numbers affected 

- name of document(s) affected 

- nam..e of data file(s) affected 

- date request satisfactorily completed 

- date new vera^ion operational 

- name of main%ainer 

- date of rev iew 

~ name of reviewer ^ . . 

- review decisi^on 



4.2 Code audit 

■ ■/ 

"The code review or audit is a procedure" used to determine how. 
well the code adheres to the coding standards and practices 
and to the design specifications. The primary objective of 
code audits is to guarantee a high degree of uniformity 
across the software. This becomes a critical factor when 
someone other than the original developer must understand and 
maintain the software. Audits are also concerned . with such 
progratn elements as. commentary, labeling., paragraphing, 
initialization of common areas, and naming conventions. The 
audit should be performed by someone other than the original 
author. Questions addressed during an audit should include: 

Are comments well constructed? 

Do the comments provide meaningful information? 
Are the comments consistent throughout the code? 
Are the constants centrally defined and locally 
initialized? 

Are the statement labels descriptive and sequential? 
Is the code formatted in a readable manner? 
Is indentation and paging used to make the code 
easier to read and understand? 



M.3 Review and approval 

Review and approval is the final phase of the software change 
control process. -Prior to installation, each change 
(correction, update, or enhancement) to a system should ^be 
formality reviewed. In practice, this process ranges rrom the 
review and sign-off by the project manager or user, to the 
convening of a change review board to formally approve or 
reject the changes. The purpose of this process is to ensure 
that all of the requirements of the change request have been 
met; thai the system performs according to specifications; 
that the changes will- not adversely impact the rest of the 
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system or .6^.her users; that al^. . procedures have been 
. f oil owed ,\aii^^^^ and guidelines adhered to; and that the 

change is.; indeed ready for installation in the production 
.system. •VAll*^ review actions and findings should be added to 
the system^^^tf^^ / 

iB.5 Testing Standards And Probedurjes 

Testing, iil<e documentation, is an ' area of software 
mainteiiance which is of ten not done .well . Whenever; possible, 
the test procedures and test da t a - . should be developed by 
someone other than the person who performed the actual 
maintenance on the system. The testing- standards and 
procedures Should define the degree and depthvof testing to 
*be performed and the disposition of tes#r-m.3terials upon 
successful completior^j!..,Qf ,;'th^ testing. • ' ' ^ 

Testing is a critical comp^onent. of software maintenance . " As 
such the test procedures must be consistent and based on 
sound principles. Whether the testfn^ is ' perf ormed^ • o^'h the 
entire system or on a single module within the system, the 
same principl^es are required. .They include the following: 

- The tes.t plan should define the expe.cted output. 

- Whenever possible, the test data should be prepared by 
somed^ne othe/^ tHan the tester. ^ 

Both the valid, invalid, expected, and unexpected cases, 
should be tested . v^' 

- The test should examine whether o^ not the program is 
doing what it is supposed to. . - ( 

- Testing is done to find errors,-notto prove. that errors 
do not exist. 

*■ 

For further information on testing, see [FIPS1 01 ] , [NBS753, 
[NBS93], [NBS98]. ■ . 



D SOFTWARE- MAINTENANCE TOOLS , - 

Software tools are computer programs which <an be used^i^ 
d^yelopine^nt, analysis, testing i mailitenanc(e^(^^ and management 
of other computer programs, and their;, ^^documentation. - This 
secfeion'. discusses some tools whip^^^^^ be useful 

maintaining a software system. Generally these tools can be' 
divided into two categories: technical , and management. The 
"technical tools can be further subdivided into those- which 
process, ' analyze, and test the system, and those/which -help 
the maintainer manipulate and change the source code and the 
documentation. The management tools assist the maintenance 
manager in controlling and tracking all,;\of the maintenance 
tasks. Table 10, lists some of the topis available to the 
maintainer and -the* maintenance, mapnager. A . glossary of 
so/tware. tpdls^^ can be found in v[.REIF;77^^^ 

v. - fable 10 - Software Maintenance Tools; . : . ; . ,: 



Technical Tools 
Pr'ocessing Topis 
Compilers'.- ^ 

Cross referencer * ^. 
Comparator 

Traces/Dumps -^.iH- 
Test data generator V < . 
Test coverage analyzer. ; . ' 
. Preprocessor 

"^V^erif ication/Validatiorf^ ■ ' 

Clerical Tools 

On-line Editor 

Documentation Library . 
- Archival Capabil ities 

Ref ormatter 

Data" Dictionary 

I Management Tools 

Problem Reporting 
Status Reporting 
Scheduling 

Configuration Management • 



9.1 Cross Rererericer 



One of the.vs most, useful aids to the maintainer is ^the 

cross refeV^ence list which accompanies the compiler source 
listing.. It usually /provides a, concise, .ordered analy„sis of 
the data variables , including the location and number of 
times'^ the variabl^s^ are used-, as well •* as other pertinent 
information about. the program. ,r 

In large systems, it is often difficult t<^ c^etermine which 
modules are called or used by other programs, and where 
wrthiri the system a specif id module vbr^: pfararmeter ■ is used. 
What is often' needed ;to/ is the capacity to produce and 
develop a- cross r.eference listing 'on an interprogram rather^ 
than on/^ an intraprogram basis. This ,. inf Grmat,ion can be 
obtained from some of the ; available cross reference 
generators. To ^the main tainer , such inij||yn,ation is useful 
when attempting to backtrack to de termihe™where ' an error 
occurred. ' w^, '; ' 



: . 9 • 2 Gompara tors ■■ ' '• ' - ■> :/'; /■ » 

. Comparators are software- tools which accept' two (or more) • 
: sets , of input and generate a'-/neport which" lists the. 
/discrepancies between ;:the input data/sets. This tool can be 
//;;:/; use for finding -changes in the source code, input, data, . 
' . program output, etc;. It is extremely -^useful to the 
.mai-ri tainer who must ascertain if a change made to the system' 
caused it to fail or work- differently/' It can also be used ^ 
to/ ensure that one set of test results is identical' to a 
previous set, or identify where the results^ have changed* 
Most comparators are developed fbr a specif ipt system. - " They ■ 
may be general , in nature or work on speci fic parts- ' of the 
system and perform specific functions^ They are- relatively 
simple to build and are very valuable tools ''in the 
maintainer's tool box. • V 

^ 9-3 Diagnostic Routines ^ 

** ' ■ • ■ ' 

Diagnostic routines^assist the maintainer ^by reducing ' the 
.•amount of time and effort required for problem * resolution;. 
- Some of the more common!;^ ursed routines include: 

- ' trace ■ which generates an^^^/a trail of actual ■■'^ ■ 

operation's during execution . . . \. 

- .' breakpoint which irTterrupts program execution to ? 

initiate debug a"ctivities .• ". ■ , r >• ■ / ' • • : 
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;i*lvc/ri::^t,iirX which^ iu^l/vages program executi on, status 
at any>voint to pl*rnill< e v al ua 1 1 on .a^d " f e- i n i t ia ti on 

siUHii^'c which Kive ll.stlngr. ( usual 1^': unformatted or 
p.Trtially format.lod) of lnll or selected ponti-ohs of 
th(^ pro^\riuii inci^iory at a sp^^cif ic point in time. ^ 

tH>nip 1 1 f r:> often i^rov Ide Tiiagnostlc capabilities that can be 
u^iorially :>el eolo'd^-lo a^si^i the ' prbgr aipmer in analyzing the;- 
rxVi'utiM.r) flow, and capture a myriad oT'tiatayat predetermined 
poiutr. iti the process: In the^ hands of • a sk|n.ed..maintainer , 
iht^r-e dia"^\no:>t ICS can help identify "the se^c tiofts .. pf code 
wlueli cati:;e the error, as well as what is taking places there . 
While tjiese aids a r e, c x I r efnel y useful, the/- -^are j usually 
•\il ter ' the fact" tools'' used to help determine what has gone 
vii'f)nh\ Willi an operational, system. Far more useful-^, are 
d ia^;riost ic capabil ities which .are* designed and imple:rnigated 
wilhin \.\\v source code as it i s -idev el opfed\, ■ latter >;type 

. f diagnostic Is normally di-s^a-bled, i-bUt can be turned on 
tliroO^'h t he use of one or more control pa r arrje ter s . 

V ' ■ ' . ■ ' 

Application Utility Libraries:;;-;,; 

N\*st operating; systems provide Support and -utility libraries 
uhu:[i contain st^a^^dar^ functional routines (square roots, 
M-nt', cosine, absolute values, etc.). In addition, HOL 
^woriip 1 .1 ers [K'we many built-in functions which c^^^ b'e utilized 
■P.y" llie pro^^^rammer to , perform standard f unc t iorts-^j.. -^'^^ Just as 
;tYe:;e libraries provide st'anda rdiz ed routines to perfoirm 
t rcces.-^es which are^ common to many,, applications systerhs, 
l.ir^.e appl iciu tiqp system^a should ^aye a procedure library 
vstiicli i. caU.axns rout ines Which ^re common to various segments 
ol the ai^pi.rceition sys.t;em^ ' These functions and utility^, 
routines shouTdrbe available to all persons working on th^ 
syste^> Iron .t,he developer to the maintainer. Application 
: i.;'pt>r't ut 1 1 It y: i ibrar ies assist by-c ' j- . 

savir,^; t i ri.e" ( t e programmer does njpt have to reinvent 
. V t r;e wtieel ) . ''^ 

* s irrpl i^fy iri^, th* changing of common* '. code (changes all 
prcgra'ns .which utili'zV;;:a modul e ) . ■ th is usually, requires 
relinking, recompiling each affected program, but 
It el'imnates. the .need to chan:ge lines of.cod'e in each, 
t f the, progr a;r:is . / . 

- encit^:in^ wider ase of u t i 1 i ty |prb'cedur es , d,e,;V el;6ped by ■ 
one person or group, by all persons working on the 
oyster::. ' 

- .1 ac 1 1 1 Id ti r g maintenance of the ^system by keeping the 
:oce ir a central library or set of librariesfv. 



In addition to the stored library rbutines, all the source 
code for the applications sy s*tem should be stored in a 
centralized, on-line library.' Access to tHis library should 
^be controlled by a librarian Who has the duty of maintaining-, 
"the integrity, of the library and the code. 

i On-lin^ Documentation Libraries • 

.. - . .... f 

System documentation normally consists of one or more foJ.ders 
or _files in* hardcopy .form which are -stored at a central 
location. The need for the maintainors to have access to^tjie 
information in .^these .documentation folders and the need 
keep the docujtienta tion up-tp-rdate and secure, are sometimes at 
cross-purpose^B f with , one ^ another. Thus, it is recommended 
that as much, documentation* as practical also be kept on-lipe 
.in documentation librarie's which the. maintainer can access at' 
any time. Updating of this library should be, controlled by. a 
librarian. 



> On-line/Interactive Change And Debug Facilitie,s • 

Interactive debugging .provides significant' M^^ntages oyer 
the batch me thod because of the convenieW^Mfcf^speed of, 

mbdif ica tion . With interactive processing, the^^^ifrtainer 
can-^ analyze the problem area, make changes to a test version 
of the si^stem, and test and debug the system immediately.. 
The;^^ alternative, to submit a batch j^b to perform the 
testing^ requires much more time to complete. While in spme« 
instances this may 'be necessary because of system size, or 
resource requirements, most maintenance activities ( including 
perfective maintenance) are highly critical problems which 
must be addressed apd solved as quickly as. possible. 
Interactive 'processing provides a continuity which enSbles 
'greater concentration on the problem and quicker response to 
the tests. ' Although the estimates of the increase in 
productivity yarY^Jl::^f^i6ely j it is clear that there is a 
substantial improvement when the maintainor has on-line 
interactiTe: processing capabilities.. 



^.7;'GenenaUon- And Retention Of Test Data 

StaiTdardized ^roce*dures (often developed in-house) for 
generating and ^retaining test data are recommended. One of 
tl^e {Perennial problems in software maintenance is the lack of 
test da'tan . ^hile in most instances, test data are generated 
by the^' maintainer , studies have found that more errors and 
"irtconsist^nc i^s * ane uncovered when test data are prepared by 
the u^rj^'and .testing is more effective if samples ^of the 
a.ctual data are included in the test data, 

^ Once a test data set has been geijerated ' and the system 
successf^ully ru^ against it, the data should be retained for 

\ ^ use *in future maintenance regression testing*^ Regress^lon 
testing i# the selective retesting of the .system to detect 
any faults wh^ch may have^ been introduced ,and ta verify that 

\ the ma-intrenance modifications have preserved the 
functionality of the system. The system testing verifies 
th.at the system produces the same results -and continues to 
meet the requirements 'specifications. In addition, 'the 
results of the testing should be saved "in machine readable 
form so that the results of future maintenance testing can be 
coppared with the previous test results through the use of a 
comparator , ' 

Although some .test'^ data set^ generators are commercially 
available, most are developed either as part of the original 
development* effor^t of a lar^e system or Ss^ part of the 
maintenance effort , A test data generator is usually built 
for a specif jc system and designed .to test the system to a 
selected' ,l^vel of detail, Guidance^ on testing iL:s available 
in several^ NBS/I.CST- publications [TIPSIOI], [NBS75], and 
[NBS93]. . ■ . 
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'10.0 MANAGING SOFTWARE MAINTENANCE 

■The effective use of good management techniques and 
methodologies in dealing with scheduling maintenance^^ 
negotiating with users, coordinating' the maintenance staff, 
and instituting the use of the proper tools and disciplines 
is 'essential to a successful software maintenance effort. 
Software maintenance managers are responsible for making 
decisions regarding the performance of software main tena^nce ; 
assigning priorities to the requested work; estimating the 
level of effort for a task; tracking the- progress of work; 
and • assuring adherence to system standards in all phases of 
the . main tenance effort. A software maintenance manager must 
not only be a good technician, but also a good manager. 
While this may seem to be an obvious point, it is, in actual 
practice, far too often ignored. 

There appears to be a common failure to recognize * the 
importance of the word "management" in the phrase* "software . 
maintenance management". In many instances, technical 
persons are promoted to positions of management within an 
organization with the assumption that • technical expertise is 
all that is required to manage effectively a software 
maintenance operation. On the contrary, a software 

■ maintenance function has the same organizational n6eds and 

. managerial problems as any other function. . 

The primary duties of a software maintenance manager include: 

1. Evaluate, assign, prioritize, and schedule 
V./ ' maintenance work requests. i 

2. Assign personnel to scheduled tasks. J 

3. Track progress of all maintenance tasks^and ensure 
tt^^at they are on or ahead of schedule. \ 

4. Adjust schedules when necessary. 

5. Communicate progress and problems to the user. 

6. Communicate progress and problems to upper 
management. 

7. Establish and maintain m-aintenance standards and 
guidelines. 

' 8. Enforce standards ajid make sure that the software 
maintenance is of high quality. 

9. Deal with problems and crises as they arise. 

10. Keep the morale of the maintenance staff high. 

This list is not complete, but is sufficient to illustrate 
the point that if the words "software maintenance" were 
deleted, it would simply be a list of management duties for 
any other organizational function. Thus, it is imperative 
"that a-,^ software maintenance manager be qualified both 
technically and managerl^al ly to hold such a positi,on. If -the 
person* is not, the ability to be an effective maintenance 
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manager will be severely diminished. 

Just as the importance of management skills has not been 
recognized in the selection of many software maintenance 
managers, in other instances the need for technical 
maintenance expertise has not been addressed. While many of 
the required skills involve dealing with and coordinating 
people, the software maintenance manager also has the 
responsibility to control the technical aspects of the 
process. Without a strong technical background and actual 
experience in performing software maintenance, the. manager 
may not be able to deal with the- conflicting needs and 
requirements of many maintenance tasks. 

The software maintenance manager should be aware of, and 
familiar with, all of the work being performed by the 
software maintenance staff. While this is not always 
practical or possible in large organizations, each specific 
application system must have a central authority who is 
responsible for controlling and coordinating the maintenance 
of that system. Too often, a form of anarchy exists in 
software maintenance organizations. The maintainers are not 
adequately coordinated and are permitted to address problems 
as they arise without adhering to established standards and 
procedures. In the short term this tnay be the most effective 
manner of addressing . immediate problems. The long term 
consequences, however, are usually a decreased level of 
maintainability for the system, and an increased need for 
maintenance. This section discusses standards, guidelines, 
procedures, and policies which will facilitate the management 
of the software maintenance function and will improve the 
capability to maintain application systems. 



. 1 Goals Of Software Maintenance Management 

The goal of software maintenance management is to keep all 
systems functioning and tQ respond to all user requests in a 
timely and satisfactory manner. . Unfortunately, given the 
realities of staffing limitations, - computer resource 
limitations, ajnd the unlimited needs and desires of most 
users, this goal is very difficult to achieve. The realistic 
goal, then, is to ke^p ^the software :maintenance process 
orderlV and under control. The specific responsibility of 
the software maintenance manager is to keep all application- 
systems runtiing and to facilitate commnriica tion be^een the 
three groups involved with software maintenance. ' ^ '^^^ 

The user must be kept "satisfied that ever^;^hing possible is 
being done ^to keep each system running^as efficiently and 
productively as possible. 
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Table 11 - Goals of Software Maintenance 



1 . Keep the maintenance procTess orderly and 
under control . 

2. Keep the application syste'm^'running. 

3. Keep the users satisfied. , ' . 

4. Keep the maintainers happy .v' 

5. Keep maintenance viewed as a positive aspect 
of ADP - one which contributes to the meeting 
of the goals of the organization; not some- 
thing that has to be done because the ADP 
staff just can't do it rig-ht the first time. 



Upper management must be kept informed of the overall success 
of the software maintenance effort and how software 
maintenance supports and enhances the organization's ability 
to meet its objectives. In dealing with upper, management , 
one of the primary responsibilities of the software 
maintenance manager is to keep maintenance viewed in a 
positive perspective. Software maintenance is an important 
effort which supports and contributes to the ability of the 
organization to meet its goals. Too many of the problems 
encountered in software ■'maintenance are the result of the 
negative attitude that it is a function which exists because 
the software support staff can "never do it right". Rather, 
the emphasis should be on the concept that software 
maintenance enables an organization to improve and expand itS: 
capabilities using existing systems. 

Finally, the software maintenance manager has. the 
responsibility for keeping the maintenance staff happy and 
satisfied. Software maintenance must be thought of .as the 
challenging, dynamic, interesting work it can be. 



10.2 Establish a Software Maintenance Policy 

A software maintenance policy should employ standards which 
describe in broad terms the responsibilities, authorities, 
functions, and operations of the software maintenance 
organization. It should be comprehensive enough to address 
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any type of change to the software system and its 
environment, inclufling changes to the hardware, software and 
firmware. To be effective, the policy should be consistently 
applied and must ■ be supported and promulgated by upper 
management to the extent that it establishes an 
organizational commitment to software maintenance. When 
supported by management, the standards and guidelines help to 
direct attention toward the need for greater discipline in 
software design, development, and maintenance. 
, , ■ ' . ^ 

The software maintenance policy must specifically address the 
need and justification for changes, the responsibility for 
•making- the changes, the change controls and procedures, and 
use of ;modern. programming practices, techniques and tools. 
It should .describe ^ni^'fl'ag role and duties in regard to 

software ' mainte.n%,H;ee^^' a define the process and procedures 
for control lii^ c:hangesf;.to: the software after ,th:e baseline 
has been estatelished. ; --(B.aseline refers to a Well-defined 
base or ' confiiuralilon;; to modifications are 

applied.) ImplementatiGn'. of^-,t,he^ has the, effect of 

enforcing adherence to rules '^regarding the operating software 
and documentation from initiation through completion of the 
requested change. Qnce this is accomplished, it is possible 
to establish the Milestones necessary to measure software 
maintenance' progress. Plans, however, are of little use if 
they are not" followed. Reviews and audits are required to 
ensure that the plans are carried out. 

The primary purpose of change control is to assure the 
continued smooth functioning of the application system and 
the orderly evolution of that system. The key to controlling 
changes to a system is the centralization of change approval 
and the formal requesting of changes. The software 
maintenance surveys found that each successful organization 
"had a formal trouble report/change request process with a 
single person or a change review board approving all 
changes/enhancement requests prior to the scheduling of work. 
When this is not dpne, the confusion which results from 
independent maintenance efforts is usually disastrous. 

Everything done 'to software affects its quality. Thus, 
measures should be established to aid in determining which 
category of changes are likely to degrade software quality. 
Care must also be taken to ensure that changes are not 
incompatible with the original system design and intent. The 
degree to which a change, is needed and its anticipated use 
should be a major consideration. Consideration should also 
be given the cost/benefit of the change: "would a new system 
be less expensive and provide better capabilities?". The 
po,_licies establishing change control should be clear, 
conqise, well publicized, and strictly enforced. 
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Table 12 - Estabi ishing ' 8;:$^ Maintenance Policy 

1. Review &nd evaluate; all requests for changes. 

- The change must b.e^ fully justified. 

- The impact ;Gn . other wpr^k and users should be 
taken into consider . 

2. Plan for .,:and • scfredu 

- Each ch,ange^^;r^^^ be assigned a priority. 

- Work $hQUl.a' b6\'^^s^^^^^ aqcording to priority. 

- The sqhe^iul"^^^^^^^ enforced and adhered to. 

3. Restrict eo.der'chaii'gGS to the approved/scheduled 

• work. ' \i:r'-' /: '.--r:. 



4 . « Enf orce^doc.u^^^^^^ and cpdi^ng s tanda rds through ' 

review^ 'and .a:udits-. . • - v, • * .: j ^ ] 

10.2.^ . Rev r^w and ,eVal uat:e - ai r r 

All ^user and. staff requests for changesv to aii^^^^^^ 
^ ^si^stem ( whether ^' enhancements, preventive >mai7iteiVancve , ' or 
. 'errors) should requested in writing and ■jsubmitted' . t fehe 
software maintenance; ma Each^'" change' requ^^ slfioul-d 

' / include not ;orily. the:^^.d of the requested xhati^ 

/ a; full jus tlfl why tha t . • cll^iig^ . siiouf d- b^'^rpade . ' 

;These - cha;nge 'req.uests; should be careful;lyv 'rev^iWed^^^ and' 
^ evaluated : •before.; a/iy factual work is performed (ih^;.t^ 
^ The eval'uati<^n. should : take into consideratioaj ^ ai^ 
: things, the : . staff; resources available ver^sus: :th!e-,*ei&ti^^ 
^ workload of ;th-e Vieques t;. the estimated additional '-'cojn^ 
resources ;: whi,ch , will be^ for th^ design, V tes^ 

and/operation .of the moxiaf ied system; and the.^time ■ahdl>:'^ c:c^S'^^^^ 
of updating the do Of course, 3ome f l'^xi'bI'laty^ 

must be buil t ^ into the process with some deiegatiotr. ..^^^^ 
authority ; to' initiate critical* . tasks . HpweveV, each i^elque^t ' 
should^ be. reyl^^^ and judged by either, the * .-sof^twa^^^ 
inain:tenaTice> . m or a change review board.^"^oln^g; so :^witi^^ 

reduce th:e amount of unnecessary and/or un jiasti f ied^ 
■ which* is .of ten performed on a system. ^ ' ' • \ 



10.2.2 Plan for, .and schedule maintenance 

The result of the review of all change requests shouldbe the 
assignment of a priority to each request and the updating of , 
a schedule for meeting those requests. In many ADP 
organizations, there is simply more work requests than staff 
resources to meet those requests. Therefore, all work should 
be scheduled and every effort made to adhere to the schedule 
rather than constantly changing course in response - t^^ . ^ . 

most visible crisis. ' 

, . ■ • --.v ■ • -' 

. '■ . ** ' 

10.2.3 Restrict code changes to the approved work 

In many cases, espect^lWyihen the code was poorly de^signed 
and/or written, 'twere iS^^^"^^ strong temptation to change other . 
sections of the code as long as the program has been "opened 
up" The sof-tware maintenance manager must monitor the work 
of the software maintenance staff, .and ensure that only the 
authorized work is -performed. In order to monitor 
maintenance effectively, all activities must be documented. 

■.. ^ includes everything from, the change request form to the 

. -'^-yi^ revised sourCe.;,pr^^ listing. . 

Permitting softwaS^m^^ to make charig-es other 

than those authorized 'can cause schedules to slip and may 
prevent other, higher priority work from being completed on 
time It is very difficult to limit the work which is. done 
on a' specific program, but it is imperative to the overall. . > 
success of the maintenance function to do so. , 

10.2./1 Enforce documentation and coding standards 

Some programmers "do not like to document, some are not good 
at it, but primarily, documentation suffers because of too 
much- press ure- a^^^ the schedule to do ^it. ^ . 

Proper and complete communication of necessary information 
between all persons who have, are currently, and who will 
work on the system is essential. The most important media \ 
.for this communication is the documentation and the source 
code'. 

It is not enough to simply establish standards for coding and 
documentation. Those standards must be continually enforced 
via technical review and examination of all work performed by 
the software maintenance staff. In scheduling maintenance, 
sufficient time should be provided to fully update the 
documentation and to satisfy established standards and 
guidelines before a new assignment is begun. 
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10.3 Staffing And Management Of Maintenance Personnel 

Selecting the proper staff for a software maintenance project 
is as important as the techniques and approaches employed. 
There is some debate on whetk^^ejr or npt an organization should 
have separate staffs for irtain tenance and development. Many 
managers have indicated that separate staf<s ca'p' improve the r^, 
effectiveness of both,. However, the realities .^of size, 
orga'nization, budge.t,' and staff ceilings often preclude the 
establ ishment of^T-Si^par ate main tenahe.e^ and development' staffs. 

Manageg^'ent must apply the same criteria to the *' maintaihers 
that, are applied to software and systems designers or other 
highly sought after professional positions . If an indi v idual 
is productive, -consistently performs well, ^"has a; good 
attitude, and displays -ini ti3tiveY-^>it should^' ;:not matter 
whether the project is development or maintenance. 'Recent 
studiesj. on the motivation, .of programrners and :analysts 
[C0UG8^] indicate thai- the^reWre^fcHree m^^ psychological., 
factors that can impact ;fche atti tu^JeV^^^i^^ ahd general' / 

performance of an indivictual. . ' . ' * ^" ! ' 

- the wgrk must be considered worthwhile by a set' of " • 
values accepted by the indlv.idual , as well as by . the 
standards employed - by; the oKganiza tipH. ' \ 

- the individual must f^jpl' a r esponsibtl^i^:^^ his, or 
her performance. There is a need to 

V .•/■jaccbuntable for the ^ ojutcome of an ef fp^rtv^ ' 

■ -,'the individual must be alple/ to determine on a regular 
.-basis whether or not the puicpme of his or her efforts 
is satisfactory. ' '■v:.-;^:-^^''l:''\'- 

When these factors are high, the indi vidual is likely to have 
a good attitude and be motivated. , ^ 

Some organizations have attempted to improve morale and the 
image of maintenance by simply renaming the maintenance 
function. This is a superficial approach. It does nothing 
to change what ;is in fact being done, or the way it is 
perceived by the maintainer and supported by management. A 
more positive approach is to acknowledge the importance and 
value of good maintenance to the organization through career 
opportunities, recognition, and compensation. 

Often, a maintainer is responsible for large amounts of code, 
much of which was developed and previously maintained by 
someone else. This code is -generally old, unstructured, has 
received -numerous patches, and is inadeqljately documented. 
The potential for errors,- delays, and unhappy users is 
considerable. Praise, thanks and recognition. are often as 
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' important as salary and challenging assignments in keeping 
good analysts and programmers. 

It is Essential* that work- .assignments offer growth potential. 
Contin^uing education is required at all levels to ensure that 
not only the maintainers, but the users, managers, and 
operators ' have a thorough / understanding of software 
maintenance. Training should include: programming 
languages^ standards and guidelines, operating systems, and 
utilities. . . . 

There is a common misperception that maintenance has to be 
dull, tedious, non-creative work which offers little chance 
for reward or advancement . . This view can only ^^^^^:^.b^^ changed 
• tfrr'QUgh management initiative's. The maintainer^ 1^^^^ critical 
pai^t of the process th-^. key to delivery .. or -^ 
b:pth ^^omised by management and desiredV"-b^^^^ users. 
Indeed, Ythe maintainer 1*6 ;brie of the most .important members 
of the application software staff. The 'importance of 
maintenance, must be acknowledged in terms of both position 
value and" function. \ 

Some points to keep in mind when managing a software 
maintenance function are outlined in Table 13. 
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Table. 13- - Managing the Software Main te'r^jS^.^ 
:^ Function . [^^r^ 





1. Maintenance is as/important as development ^fi'd^ . • 
just as dif f icul t, and chal'lenging . ' * : ' ' ' J 

• •. . ' ' , 

2. Maintainers should- be highlry qualified., ,compe t^i',^^ . 
dedicated professionals. 'The staff should include'^, ./ 

...both senior and jiinior personnel . Do* not*. short ^^^.^'^ 
change maintenance. Don' t isolate the mair>tenance . 
staff. , ' ' \ 

3. Maintenance ^shoul'd ' ftOT be used as a training 
ground where jqnlor staff are left to 
"sirik-or-swim" . > 

• ■ ' . ' ,■ » ■ 

4. Staff membe/rs should bk rotated so they are 
assigned tfS( both maintenance and development. 

It takes a good dev's^loper to be a good maintainer, 
and^ conversely, it takes a good maintainer to be 
^a good developer. 

5. Good maintenance performance and good development 
performance should be equally pewaP'ded.- 

6. There should be an emphasis on keeping the staff 
>well trained. This keep performance at an 

optimum level and help to minimize, morale 

pr obi ems. [ '.-j 

. - 'A ■ ' 

7. Rotate assignments. Do not permit a system or a 
. major part of a syistem to become someone's V 

private domain. .^^ ^ 



1 1 .0 SUMMARY . .. 

While the ICST survey identified sof.tV/are jnaintenance problems 
vihi'Gh 'w.ere' both managerial and technical in nature, management 
is clearly the most .important factor in improving the software 
'-maintenance process. Most of the problems cited in the survey 
were the result of inadequate management control and review of 
software ma^intenance activities. Management mit*rt take a closer 
look at how the software is .maintained , exercise better o control 
over the process, and ensure that effective software maintenance 
techniques and tools are employed. 

Recommendation^^ have been made in sections. 7.0 through- 10.0 of ' 
this report ;to help a manager gain better control, and to help 
the maintainor, improve the quality of the maintenance performed. 
In, order , toi maintain control over the software maintenance 
process ari;l ensure that the maintainability of the system 
does not deteriorate, it is important that software maintenance 
be anticipated and planned^/f or . 

The quality and maintainability of a ; software system often 
decrease ' as the system grows older. This is the result of man.y 
factors whicji, taken one at a time, may not seem significant but 
'become, cumulative and often, result, in a system which is very 
difficul.t to maintain. Quality programming capabilities and 
techniques are readily available. ^However, until a firm 
discipline is placed on how software maintenance is performed, 
and that diiscipi ine is= enforced , many systems will be permitted 
to deteriorate to the point where they are impossible to 
maintain . , 

■ < 

Software maintenance must be performed in a structured, 
controlled manner. I,t is simply not enough to get a system "up 
and running" after it breaks. Proper management control must be 
exercised over the entire process. In addition to controlling 
the budget, schedule, and staff, it is essential that the 
software maintenance manager control the system ar^ the changes 
to it. The now .freque^ntly cited maxim that a system "must be 
developed with maintenance in mind" is insufficient; a system 
^Iso must, be maintained with future mai;ntenance in mind. If 
this is 'done, the quality and maintainability of the code 
actually can improve. Otherwise, today ' s maintainable systems^ 
are destined to become tomorrow's unmaintainable- systems. 
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APPENDIX I . 

« 

Software Main tenapce- Definitions 



"Software maintenance in its broadest sense, includes error 
corrections, change3(also called modifications or amendments), 
enhancements, and improvements to the ^ existing software. It 
includes maintenance of all s<5^tware,* including struct\ured 
(software developed using structured technologies) and 
unstructured software (software developed without ...). " 

Garish Parikh,"World of Software Maintenance" 
Techn iques oT Program aM Sy^tHpi Maintenance. 
1981 



Maintenance i% "the process of ^modifying existing operational 
software^ while leaving its primary functions intact." 

Barry Boehm, "Software Maintenance", 

IEEE Transactions qr Software Engineerinii. 

December, 1976. 

"Maintenance is^ the cjbntinuing process of keeping the program 
running, or improving its chara teristics" 

C' 

J.L. Odgeft,*- "Designing' Reliable Software," 
reprinted in [PARI81] 

"Most generally , ^ it is theVpf-oeess 'df' adaption , i. i., updating 
existing .systems functions to reflect 'new co^nstraints or 
additional features." - 

Chester Liu,^"A Look At Software Maintenance", 
reprinted in'iPA'RlSf] ' 

"Traditionally program maintenance has been viewed- as a second 
class activity, wi^th an admixture of on-the-job training for 
beginners and of low-status assignments for the outcasts and the 
fallen. ^ . / ' ^ / 

* Richard.Gunderman , "A Glimpse into Program 
Maintenance" , reprinted in [PAft^lSl^] 



"Maintenance is. the process of ..being sresponsive .to user needs 
fixing errors,, making , user-sp6crified modifications, honing the 
program to be more'^us'eTul . " . ! \ ' ' 

"Software main tenance • • > • fs the act of takirTg a spftwar^ product 
that has already been delivered to a customer and/is. i;n use by. 
him, and keeping it functioning in a sa ti sf actory*: vray^ ," . 

"■ ■ * • ■ 1 ■ /"^ ■ *#• 

R.L.Glass and R.A.NoiSeux, Software ^ ^ * ■ * • 

Maintenanc e Guidebook / 1 981 . . ' / ^ 

"Systems maintenance includes any acti v ity ^needed to ensure, that 
application programs remain in satisfactory working .-pondition. " 

I W.E.Perrj, Managing Systems . Main.teriaDq,e 1981 . * - 

"...changes that have to be made to, computer , programs after they 
have been delivered to the customer or user."' ' \r,. - , 

James Martin-dnd Carma McClur e, ■ Software . ^ 
Maintenance - ' The Problem - and^ Its Solptron , \ 

1983. ' ^ : ' - ■ 

' ■ ,'- 

"The maintenance of sof.twarerrincludes two majj 
removal of defects and the enhancement- o,f 

Werner S, Frank/ . Critical ' Issues 
A Guide tp Sof tware;: Econoroios^ S. 
Profitability . 1 983^; 
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